Lifeline/TKB switches
-
Yes indeed they do. It seems to be the reporting back to controller is not quite working yet when switched by the thermostat. I associated them in Group 2 with the thermostat and it seems to control them nicely. Just unable to know whether they are on or off. If switched on or off in the gui they work fine.
Mine are all interviewed 100% also but does it need an association command class to do what I think it needs to do? (lifeline to controller?)
-
Ah, I see. Is there anything I can try further to help, then?
-
Thank you very much - much appreciated. I'll try tinkering some more.
-
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
-
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?
-
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.
@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.
-
IF I understand this, it's to do with additional, Group 2, ..., associations. The instant status works just fine.
-
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.
-
Yep then use niffler. So I misunderstood the problem, sorry but the solution is the same...
-
Omg - just caught up reading Niffler. You guys rock - but I need a drink first. Cheers !
-
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 -
@powisquare said in Lifeline/TKB switches:
Would it matter I have a UZB and not Razberry?
Should not make any difference, AFAIK.
-
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?
-
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).
-
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. -
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 -
My SDK version shows 5.02.02, yours is 4.54.00.
I wonder if this is significant?
-
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....
-
ArcherSreplied to akbooer on Mar 6, 2021, 7:53 PM last edited by ArcherS Mar 6, 2021, 4:42 PM
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.
-
@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.
15/33