Z-Wave Future....

[powisquare]

Thank you very much - much appreciated. I'll try tinkering some more.

[powisquare]

It would appear some scripting is needed to get these working ... definately getting in to the deeper end now. The switch does not support associations but vera may have had some sort of workaround. Is there a guide on how to create modules? This would need to go in it ...

function Fix_TKB_TZ68(deviceId) {
var dev = zway.devices[deviceId];
dev.data.nodeInfoFrame.bind(function(type) {
if (type == 0x41 /* Updated | PhantomUpdate */) {
dev.SwitchBinary.Get();
}
});
}

taken from https://forum.z-wave.me/viewtopic.php?f=3422&t=20621

[akbooer]

I've hardly ever (in fact, only once) found a personal need for using device associations (aside from Group 1 controller associations, which are, on the whole automatic.)

What's your use case? Why not just do this with a scene?

[rafale77]

So I went through my entire device list to find only one type of devices I own which does not support association. They are unfortunately not devices which can be manually actuated and z-way is the only one actuating them so they do not require instant status as z-way just polls them after every actuation to make sure that the device reached its target status (in my case they are vents which act like dimmers)

If these TKB switches don't have a lifeline association then they may not support instant status at all and it could be that the vera was just making status equal to the target every time they were actuated? If that's the case then a small plugin on z-way could probably fix this: I modified Niffler for my locks because of a delayed status report from my locks but it could apply to other zway devices as well. The problem I had was that z-way was polling the device too quickly after the lock actuation command and reporting back the wrong status.

GitHub - rafale77/Niffler: Workaround for Z-Wave devices that does not send unsolicited reports

Workaround for Z-Wave devices that does not send unsolicited reports - rafale77/Niffler

@CatmanV2 however appears to say that his work so I am wondering if it is a configuration/interview issue still or maybe a downrev firmware on your devices.

[akbooer]

IF I understand this, it's to do with additional, Group 2, ..., associations. The instant status works just fine.

[powisquare]

Thermostat controls 2 x TKBs turning on/off heaters via association (have tried Group 2 & 1). That works and have reactor contolling it. UI however does not know the switches have been turned on by thermostat. The workaround seems such that when the switch issues its nif on changing state (instead of a status report), controller will request status report on receiving nif.

[rafale77]

Yep then use niffler. So I misunderstood the problem, sorry but the solution is the same...

[powisquare]

Omg - just caught up reading Niffler. You guys rock - but I need a drink first. Cheers !

[powisquare]

Installed and appears to be functioning but status of added devices still not changing. Would it matter I have a UZB and not Razberry?

[2021-03-06 09:17:19.958] [I] [core] Niffler: stop() called
[2021-03-06 09:17:19.959] [I] [core] Niffler: unNiffling existing devices
[2021-03-06 09:17:19.961] [I] [core] Niffler: getdeviceindex: ZWayVDev_zway_32-0-37
[2021-03-06 09:17:19.961] [I] [core] Niffler: unNiffling ZWayVDev_zway_32-0-37
[2021-03-06 09:17:19.962] [I] [core] Niffler: getdeviceindex: ZWayVDev_zway_43-0-37
[2021-03-06 09:17:19.963] [I] [core] Niffler: unNiffling ZWayVDev_zway_43-0-37
[2021-03-06 09:17:19.969] [I] [core] --- Stopping module Niffler
[2021-03-06 09:17:19.973] [I] [core] --- Starting module Niffler
[2021-03-06 09:17:20.053] [I] [core] Niffler: init
[2021-03-06 09:17:20.057] [I] [core] Niffler: Niffling device ZWayVDev_zway_32-0-37
[2021-03-06 09:17:20.058] [I] [core] Niffler: getdeviceindex: ZWayVDev_zway_32-0-37
[2021-03-06 09:17:20.059] [I] [core] Niffler: Niffling device ZWayVDev_zway_43-0-37
[2021-03-06 09:17:20.059] [I] [core] Niffler: getdeviceindex: ZWayVDev_zway_43-0-37
[2021-03-06 09:17:20.060] [I] [core] Niffler: Niffling device ZWayVDev_zway_14-0-37
[2021-03-06 09:17:20.060] [I] [core] Niffler: getdeviceindex: ZWayVDev_zway_14-0-37
[2021-03-06 09:17:20.060] [I] [core] Niffler: Niffling device ZWayVDev_zway_8-0-37
[2021-03-06 09:17:20.060] [I] [core] Niffler: getdeviceindex: ZWayVDev_zway_8-0-37
[2021-03-06 09:17:20.060] [I] [core] Niffler: Niffling device ZWayVDev_zway_28-0-37
[2021-03-06 09:17:20.060] [I] [core] Niffler: getdeviceindex: ZWayVDev_zway_28-0-37
[2021-03-06 09:17:20.061] [I] [core] Niffler: Niffling device ZWayVDev_zway_13-0-37
[2021-03-06 09:17:20.061] [I] [core] Niffler: getdeviceindex: ZWayVDev_zway_13-0-37
[2021-03-06 09:17:28.249] [I] [zway] Adding job: Get background noise level
[2021-03-06 09:17:28.258] [D] [zway] SENDING: ( 01 03 00 3B C7 )
[2021-03-06 09:17:28.260] [D] [zway] RECEIVED ACK
[2021-03-06 09:17:28.268] [D] [zway] RECEIVED: ( 01 05 01 3B A7 A5 C2 )
[2021-03-06 09:17:28.268] [D] [zway] SENT ACK
[2021-03-06 09:17:28.268] [D] [zway] SETDATA controller.data.statistics.backgroundRSSI.channel1 = 167 (0x000000a7)
[2021-03-06 09:17:28.268] [D] [zway] SETDATA controller.data.statistics.backgroundRSSI.channel2 = 165 (0x000000a5)
[2021-03-06 09:17:28.269] [D] [zway] SETDATA controller.data.statistics.backgroundRSSI.channel3 = 127 (0x0000007f)
[2021-03-06 09:17:28.269] [I] [zway] Job 0x3b (Get background noise level): RSSI Ch#1: -91 dBm, Ch#2: -91 dBm, Ch#3: invalid
[2021-03-06 09:17:28.269] [D] [zway] Job 0x3b (Get background noise level): success
[2021-03-06 09:17:28.269] [I] [zway] Removing job: Get background noise level

[akbooer]

@powisquare said in Lifeline/TKB switches:

Would it matter I have a UZB and not Razberry?

Should not make any difference, AFAIK.

[rafale77]

As @akbooer said, that should not make any difference. I guess I am still not completely clear on how your device is setup. Are you saying you have already the lifeline association setup with the z-way controller and that you are not seeing status update when another associated device actuates the switch? Or is it that you can't setup any associations?

[powisquare]

The switch is unable to set up associations and has no lifeline (the thermostat can make associations and the switch is in the thermostat's group however if that makes sense).

[rafale77]

It does... But other people appear to be able to see the lifeline association on the switch it seems? Is your z-way node ID number "1"? I have seen devices having their lifeline hardcoded in their firmwares.
There is always a possible workaround. I could even give a scene code to get zway to poll the switch status when the thermostat state changes for example. Niffler probably won't work because zway is not even receiving any signal from the switch that anything has changed.
Otherwise it seems like you either have an older firmware on your switch or they are not fully interviewed but you seem to have already explored that.

[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?