UZB/RaZberry Firmwares - Update

[powisquare]

Zway is on node 1. Tried looking for firmware - not too sure how to go about it? Then I would gladly utilise your code : )

Investigated the logs and there is no appearance at all from switches after turning them on/off from thermostat. When the on/off button on the switch itself is used they show up correctly in UI! This is how it looks in the log using switch on/off button (switch being node 32) ..

[2021-03-06 18:30:53.238] [I] [core] HK: updated ZWayVDev_zway_90-0-50-0
[2021-03-06 18:31:06.693] [D] [zway] Job 0x3b: deleted from queue
[2021-03-06 18:31:09.481] [D] [zway] RECEIVED: ( 01 0E 00 49 84 20 08 04 10 01 25 27 70 86 72 87 )
[2021-03-06 18:31:09.481] [D] [zway] SENT ACK
[2021-03-06 18:31:09.481] [I] [zway] Node info received: 32
[2021-03-06 18:31:09.481] [D] [zway] SETDATA devices.32.data.basicType = 4 (0x00000004)
[2021-03-06 18:31:09.481] [D] [zway] SETDATA devices.32.data.genericType = 16 (0x00000010)
[2021-03-06 18:31:09.481] [D] [zway] SETDATA devices.32.data.specificType = 1 (0x00000001)
[2021-03-06 18:31:09.482] [D] [zway] SETDATA devices.32.data.deviceTypeString = "Binary Power Switch"
[2021-03-06 18:31:09.482] [D] [zway] SETDATA devices.32.data.nodeInfoFrame = byte[5]
[2021-03-06 18:31:09.482] [D] [zway] ( 25 27 70 86 72 )
[2021-03-06 18:31:09.482] [D] [zway] SETDATA devices.32.data.lastReceived = 0 (0x00000000)
[2021-03-06 18:31:09.496] [I] [zway] Adding job: Basic Get
[2021-03-06 18:31:09.501] [D] [zway] SENDING (cb 0x96): ( 01 09 00 13 20 02 20 02 25 96 56 )
[2021-03-06 18:31:09.503] [D] [zway] RECEIVED ACK
[2021-03-06 18:31:09.508] [D] [zway] RECEIVED: ( 01 04 01 13 01 E8 )
[2021-03-06 18:31:09.508] [D] [zway] SENT ACK
[2021-03-06 18:31:09.508] [D] [zway] Delivered to Z-Wave stack
[2021-03-06 18:31:09.552] [D] [zway] RECEIVED: ( 01 18 00 13 96 00 00 04 01 B1 7F 7F 7F 7F 01 01 03 0D 00 00 00 02 01 00 00 DB )
[2021-03-06 18:31:09.552] [D] [zway] SENT ACK
[2021-03-06 18:31:09.552] [I] [zway] Job 0x13 (Basic Get): Delivered
[2021-03-06 18:31:09.552] [D] [zway] SendData Response with callback 0x96 received: received by recipient
[2021-03-06 18:31:09.552] [D] [zway] SETDATA devices.32.data.lastSendInternal = **********
[2021-03-06 18:31:09.552] [D] [zway] SETDATA devices.32.data.lastSend = 8370790 (0x007fba66)
[2021-03-06 18:31:09.552] [D] [zway] Job 0x13 (Basic Get): success
[2021-03-06 18:31:09.552] [I] [zway] Waiting for job reply: Basic Get
[2021-03-06 18:31:09.592] [D] [zway] RECEIVED: ( 01 0D 00 04 00 20 03 20 03 FF B0 00 01 0D B5 )
[2021-03-06 18:31:09.592] [D] [zway] SENT ACK
[2021-03-06 18:31:09.593] [D] [zway] SETDATA devices.32.data.lastReceived = 0 (0x00000000)
[2021-03-06 18:31:09.593] [D] [zway] Received reply on job (Basic Get)
[2021-03-06 18:31:09.593] [D] [zway] SETDATA devices.32.instances.0.commandClasses.32.data.level = 255 (0x000000ff)
[2021-03-06 18:31:09.593] [D] [zway] SETDATA devices.32.instances.0.commandClasses.37.data.level = True
[2021-03-06 18:31:09.816] [I] [core] Notification: device-info (device-OnOff): {"dev":"TR Dining Room","l":"on","location":3}
[2021-03-06 18:31:09.818] [I] [core] HK: updated ZWayVDev_zway_32-0-37
[2021-03-06 18:31:11.661] [D] [zway] Job 0x13: deleted from queue
[2021-03-06 18:31:16.445] [I] [zway] Adding job: Get background noise level

[akbooer]

My SDK version shows 5.02.02, yours is 4.54.00.

I wonder if this is significant?

[rafale77]

Definitely an indication that you have different firmware versions. Not sure whether it is updatable though. I don't have any of these devices so it would be hard for me to help. The missing lifeline association makes them non-zwave compliant (at least not zwave plus). If they can't be updated, the only thing I can think of is to find an event (thermostat state change?) to send Basic.get command to the switch so you can get the updated status. At that point though, it is partially defeating the purpose of the direct association and you might as well use a scene to turn them on and off....

[ArcherS]

Edit: I have the TZ67 not the TZ68

I have two TKB devices also (TZ67 Dimmers, not the switch).

My dimmers are both also on version 4.54.00. They are stuck on 88% interview in Z-way, NodeNaming never get interviewed.

Not exactly the same problem as for @powisquare, they do change state in the gui when triggered by a scene.
They do however not report back state when you press the button on the device.
They do not have any association either, no lifeline and not possible to add any associations. So I would say that the old FW could very well be the reason even though I have the dimmers.

I have used them in places where you never press the button on the device, then they are useful, but mostly I do not use them.

[powisquare]

@rafale77 said in Lifeline/TKB switches:

Definitely an indication that you have different firmware versions. Not sure whether it is updatable though. I don't have any of these devices so it would be hard for me to help. The missing lifeline association makes them non-zwave compliant (at least not zwave plus). If they can't be updated, the only thing I can think of is to find an event (thermostat state change?) to send Basic.get command to the switch so you can get the updated status. At that point though, it is partially defeating the purpose of the direct association and you might as well use a scene to turn them on and off....

Noted - the idea of direct association is if scene controller is inaccessible for any reason thermostats/heating still function. Your solution seems a good one.

[rafale77]

How about you use it as a redundant failover? Essentially setup both the association and the scene. If the controller goes down, the association still works. Since it is down, you don’t need the status update. If it is up then the switching is done by the scene...
@ArcherS, It is actually exactly the same problem you are observing. Switching the device from another controller through association is essentially the same thing as manual switching. It is not reporting instant status to its lifeline controller so it requires a poll event (aka Basic.Get) to be sent from the controller. The old style way to do it was regular interval polling which I don’t recommend. Event polling like Niffler or in this case through a scene should work without creating traffic.

[powisquare]

Yes - could try AVT perhaps. Hope there would be no conflict between that and thermostat sending opposing commands. Perhaps the thermostat algorithm is predictive and may shut a switch off before temperature is reached (could be entirely wrong of course). If I had 4 x AVTs running would that overload openLuup in any way?

[powisquare]

Thanks all - took the easy route and ordered new switches.

[akbooer]

What make did you go for?

[powisquare]

Aeotec smart switch 6 - hope it's a decent choice. Look better anyway.

[rafale77]

@powisquare

It is decent. i have an aeotec smart dimmer 6, so similar. Be prepared to not have 100% interview completion again though because Aeotec is also one of these not completely compliant to z-wave vendors. They declare a bunch of command classes in their device NIF but then during interviews you get to find out that they are not implemented in the firmware so you end up with a bunch of incomplete stuff. They are not critical command classes but can make some controllers go nuts.
You will also get different command class depending on whether or not the device is securely included or not.

[powisquare]

I found trying to include some devices securely problematic - aeon heavy duty switches. Maybe the route went through those old TKB switches that are not zwave +. So all devices have been included without security and everything seems to work well. Have two aeotec smart switches both up to 100% (love how zway tells you what has been succesful or not when including devices). Your command classes seem to be repeating?

[rafale77]

Yes because on the dimmer they have multiple instances. The dimmer maybe a little more complicated. It has instances to control the color and brightness of the led around the plug which apparently has not been fully implemented in the firmware.