After a major hassle got z-way running on my ubuntu 16 VM with a USB pasthough UZB1 stick including license and connected to Vera...
I see:
I also see:
0d6e8c78-c8cd-4307-9474-23e0d6a55094-image.png
But how do I update that?
e09ffa19-a31d-4a03-8983-01228bc5478f-image.png
Hey guys ... I've started creating a Docker container for Z-Way.
I was previously using the Razberry2 but found it a bit slow on my Raspberry Pi 3. I could upgrade to a Raspberry Pi 4 but since I already run a dedicated Linux server and many Docker containers I thought it might make more sense to run Z-Way on there.
GitHub: https://github.com/sofakng/docker-zway
DockerHub: https://hub.docker.com/repository/docker/sofakng/zway
This container is based on other containers that are no longer updated: (ruimarinho/docker-z-way) and (EugenMayer/docker-image-zway)
I'd love to hear feedback and any improvements that might be needed.
One thing I want to add immediately is to separate the configuration files from the Docker volume but it looks like Z-Way has several user configuration files/directories?
$ZWAY_DIR/config/Configuration.xml $ZWAY_DIR/config/Rules.xml $ZWAY_DIR/config/maps $ZWAY_DIR/config/zddx $ZWAY_DIR/automation/user_syscommands $ZWAY_DIR/automation/storage $ZWAY_DIR/automation/userModules $ZWAY_DIR/htdocs/smarthome/user $ZWAY_DIR/config.xml
Not 100% sure this is the best place, but this seems to be the sticking point.
Background: My NotVera system has been working perfectly now for some years. USB Z wave stick in an old Intel NUC.
The NUC has a bare metal install of Debian buster, and on that we have:
Z-wave Smart Home
OpenLuup
AltUI
MSR
Mosquito server
Home Automation Bridge.
I also have a bare metal Raspian install of Home Assistant running on a Pi
Due to my Buffalo Linkstation doing some odd stuff (like suddenly disconnecting, while maintaining everything was fine) I bit the bullet and bought a Synology DS224+
Now, given the age of my NUC I'm thinking that I should probably start thinking about how to replace / safeguard it. Pretty happy that I can make an image of the existing disk and drop it onto a virtual machine in the Synology, or re-install / restore or do some other things (not decided what yet) but I get stuck on the USB dongle.
Can I connect that to a VM on the NAS, or do I need another solution?
TIA
C
I have a Razberry v2 with firmware v5.04, and Bootloader v8aaa with CRC 35498 (I did manage to upgrade to this version using the "ZMESerialUpdater" tool ). I want to upgrade the firmware to v5.27, which Z-Wave.me Support say is the newest version that my hardware can handle without bricking it. Firmware v5.27 introduces the Analytics tab, according to Poltos, which is what I want.
I have been studying the firmware map (https://service.z-wave.me/expertui/uzb-stats/versions-graph.html?with_hidden) which I sort-of understand. I have also got the "ZMESerialUpdater" tool to do the update, and could use it if I knew which binaries to use.
My question is, what firmware update route do I use to get from v5.04 to v5.27? What exactly are the URLs of the binaries (as in "UPD_FIRMWARE_Razberry500_from_05_04_to_05_07.bin")?
Somewhat confused!
ScotsDon
Hi all, I hope someone could drive me in the right direction.
I was setting up a new zware environment using a UZB stick I bought about 2 yeasr ago and never used.
This stick was using firmware 5.27 that sounded to me a bit old.
So I looked on the process of upgrading the device and I downloaded the ZMESerialUpdater, the I went on the z-wave.me site and look for the firmware and I found (on this awfull map) the firmware UPD_FIRMWARE_UZB_STATIC_2ch_ZME_05_1b_04000001_ZME_05_24_04000001.bin (that AFAIK should upgrade from version 5.27 to 5.36).
I run the update and it never finished....
8899ae1b-c9cc-488b-ba15-870bbf66c044-image.png
After 2 hours waiting for nothing, I finally CTRL-C and removed and reinserted the USB stick that is not recognized anymore.
I really think I won a nice peace of plastic usb shaped, but in case someone has an idea, I would be pleased to read your coment.
Regards
The expertUI of Z-way has a very interesting menu called analytics which I have not seen on any other controller.
My engineering curiosity and OCD tendency to want to optimize everything lead me to dig into it to see if I could get things working even better... even though nothing seem to be broken since my move from the UI firmware to z-way. So the background noise menu was of particular interest.
So here it is: This was my first shot of the starting block on the left side of this graph and you can see that at around 21:00 I did something to reduce the noise. My zwave.me uzb is connected to the vera through a usb extension cable and a usb hub but initially the vera and usb hub were sitting only a 6-7 inches (20cm) away from the uzb. Keep in mind the scale on both channels. What I did was to move the vera away from the uzb stick, to about 80cm but the big step was for me to use some metal leftover amazon gift card boxes I had from christmas and covered the usb hub with them. The step back up was me moving these macgyver shields around.
Screen Shot 2020-03-25 at 07.12.46.png
Next step is still goofing around with the shields to see if I could optimize further and while I initially made it worse, you can see that it got a little better later on. That USB hub is quite noisy.
Screen Shot 2020-03-25 at 13.41.30.png
After sometime, I just thought that the whole thing is just too sensitive any movement around that area could potentially cause problems. So I decided to remove the hub connected to the vera which really was just allowing to extroot the vera. Since I am no longer using the vera as a vera but only as a remote serial bridge, which doesn't write anything on its drive, I took it out. Again look closely at the scales. It did take the noise down another notch.
Screen Shot 2020-04-14 at 08.06.27.png
Now the stick is still sitting 14inch away from a UPS with a bunch of wall warts connected to it, powering a variety of devices like a hue 2 hub. I had the idea of replacing just the wall wart (AC-DC power supply) for the vera with a POE splitter. Since channel 2 is already hovering around the detection limit, I am only showing channel 1 here
Screen Shot 2020-04-15 at 19.03.27.png
This last step alone enable me to flip this other statistics menu:
Screen Shot 2020-04-24 at 07.36.36.png
It not only significantly decreased the CRC error rate but also made the foreign network impact greater that the CRC error bar negating the success on reception for the first time. When I took a zniffer to look into what these CRC error frames were, I discovered that they were all from my neighbor's network which is distant and have obviously poor signal strength. (Yes I can see his HomeId from the zniffer). The fact that I see less error means that my controller's range is greater. It is now able to recognize frames which are from my neighbor's instead of saying they are corrupted... Also The back off frames number decreased indicating less wasted/repeated frames on the network.
I have installed my UZB1 stick on my RP4 and want to megrate my device form my Vera to z-way. Now I want to use my Roller shutter 2 in z-way.mev as a scene controller. This is activated by 2x / 3x clicks on the switch. This works perfectly with vera (verabridge) in openluup and reactor using variable LastSceneID and LastScenetime.
56982a19-5d9a-44cf-9888-bed4e8866877-image.png
Fibaro documentation:
1703e550-dedc-482c-832e-b23ac5206f6e-image.png
When using z-way.me and z-way bridge it works differently. In reactor I see the variable below. I don't know how to use it. Maybe someone else can help me.
Lagging a little here but I just upgraded my z-way-server version and couldn't find much information on their website or even forum.
What is interesting for the ubuntu/debian version is that it is now released as a .deb package making upgrades much easier. I just downloaded the package and ran:
dpkg -i z-way-*.deband nothing else. The previous versions required some manual work since it was just a bunch of files for us to overwrite our installations.
From the release note, there could be interesting things for some folks here. It is a pretty long list compared to the previous incremental release.
For all systems backup is a vital part of the long-term usability.
I thought that I describe my set up with Z-way so far. Hopefully others can fill in with their backup thoughts as well. I am sure that there are much more streamlined ways of doing this and hope to learn from you all.
I run Z-way on a Raspberry Pi 3B+ with a daughter RaZberry card. In order to reduce the risk of getting corrupt SD cards I have it running off an SSD. So far this works very well. Setting it up was really easy just reading a standard Raspbian image onto the SSD. The only minor obstacle was that I had to test a few old 2.5" enclosures to find one that the Pi liked.
The Pi is then also powered via an UPS, hopefully this will avoid problems in the event of power outages.
In order to backup Z-way I have so far done manual backups from the regular Smarthome backup & restore function creating .zab files and from the Expert UI creating .zbk files. As far as I have understood the .zab files which are bigger contain more information than the .zbk files. The strategy so far has been to make backup files after each inclusion/exclusion. Also before updating Z-way. I have yet to test restoring from these files.
From Smarthome it is also possible to set up cloud backup. I have not yet set up this as I need to decide that it is safe enough to do so. On the other hand I had this set up on my two Veras.
It would have been nice to be able to schedule a local backup of Z-way instead of having to put them in the cloud, perhaps from OpenLuup via the Z-way bridge?
In addition to the built in backup function I try to do complete image copies of the SD cards on my Pi's with Win32DiskImager. When I moved to an SSD the image file grew to the size of the SSD since it is a raw copy including all the empty space. Image files of 160GB are not practical to handle so I found a good instruction on how to shrink the .img file with Gparted in Linux: https://steemit.com/raspberrypi/@wizzle/shrink-raspberry-pi-images-using-windows-virtualbox-running-raspberry-pi-desktop
By shrinking the .img file with Gparted it is now a more reasonable 4GB. These file are stored on my NAS for safekeeping. The strategy here so far is to make a new image file before updating Z-way and to use these in combination with more frequent Z-way backups.
I have tested restoring a Gparted shrinked .img file to the SSD when my Z-way for some strange reason became unreachable through the regular UI but remained reachable through the Expert UI. Always good to test the restore function and to see that it works. 🙂
The downside of the .img strategy is that I need to power-off the Pi for a while when making the backup. However if the Z-way backup files work then the complete .img backup need not be done so very often.
//ArcherS
Have found these videos very informative as a zway(ve) novice ....
Have a number of TKB plug switches (TZ68) that are not reporting to the controller. Believe they should be associated to Z-Way in Group 1 but am not able to get the devices to report groups in the interview/call for NIF process and so there are no associations possible. Thermosat is telling them to come on/off (hurrah!) but they don't report their on/off status in the gui.
In Associations tab: Can not configure associations: groups were not reported by the device. Do interview.
Night and day difference for me. I think I was getting a lot of interference in my media closet. Devices were very slow to respond and sometimes not at all. Switched to UZB and used a USB extender to place it a good 5 ft from the location of my pi. Now things are fast and reliable.
(Solved - presume pijuice hat was upset battery wasn't connected. Took out the plastic protector and UZB now showing. Next - upgrade UZB firmware)
Have I missed something? UZB not showing up in Zway ...
Downloaded Raspberry Pi Imager and used to set up os (Buster) on an 8gb SD
https://www.raspberrypi.org/software/
Then installed Zway from Terminal
wget -q -O - https://storage.z-wave.me/RaspbianInstall | sudo bash
Plugged in UZB
Changed port to /dev/ttyACM0 in menu/apps/ZWave network access in basic UI
This arrived today - hope it has enough juice for the uzb.
https://coolcomponents.co.uk/products/pijuice-hat-a-portable-power-platform-for-every-raspberry-pi
Shame the cases are sold out everywhere.
Just upgraded to 3.1.0 and am happy to report that it has not impacted the z-way bridge for openLuup.
I am now seeing the SDK version for firmware 5.39
Hi guys,
Does anyone know if the UZB supports Long Range already? I can't find which chip is in there.
Probably @rafale77 will jump on this question first 😉
I'm using the new model of GE/Jasco switch (they replaced the dead one I got) and the new model is having also S2 security and send instant status update BUT,
And probably @rafale77 will say yes, is it possible that interference can do that I'm missing some instant update status ?
Often, I'm having the wrong status in the zwave.me web interface...and even clicking the icon, the status didn't changed to right one.
I also try to do some "On/Off" using the web interface, and the device itself physically, toggle without a problem, but the web interface is still no correct.
I'm trying to monitor the indicator command class of a 5 button scene controller in Z-Way so openluup can properly create and track it.
seems like Z-Way COMMAND_CLASS_INDICATOR (0x87 or 135) are not being monitored by the ZWave module as I couldn't find anything for this command class in (/z-way-server-path/automation/modules/ZWave/index.js)
When a Get or Set Indicator command class request is sent to the controller. ZSniffer picks up the request and response just fine although this packets are not being monitored by the zwave module
Example:
the answer looks like:
[2020-04-24 19:59:36.261] [I] [zway] Waiting for job reply: Indicator Get [2020-04-24 19:59:36.281] [D] [zway] RECEIVED: ( 01 0B 00 04 00 02 03 87 03 01 B6 00 C2 ) [2020-04-24 19:59:36.281] [D] [zway] SENT ACKI’d like to store the Indicator response “RECEIVED” correctly. I believe by modifying the index.js of the zwave module could do the trick and once the module start tracking the indicator command class values as a metric then openluup's z-way plugin would properly track any changes as well.
I'm wondering if anyone around here could share any thoughts or comments that could make it easier...
Posting here, as the z-wave.me forum seems desolated..
I have two multisensor 6 sensors, and one of them is not sending motion sensor updates?
Looking at the configuration, they are both registered as battery sensors for som reason, even if they are USB powered. They respond quickly to parameter changes, except for parameter 100 and 110, that will not update.
Any clues? How do i convince the controller that they are USB powered?
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?)
-
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
-
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.
-
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.
-
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 -
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....
-
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.
