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
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.
https://storage.z-wave.me/z-way-server/
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-*.deb
and 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 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.
(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
https://z-wave.me/z-way/download-z-way/
Plugged in UZB
Changed port to /dev/ttyACM0 in menu/apps/ZWave network access in basic UI
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:
ZWayIP:8083/ZWaveAPI/Run/SendData(NodeID,[ Command_Class, Instance, Value ])
ZWayIP:8083/ZWaveAPI/Run/SendData(2,[ 0x87, 0x01, 0x01 ]) (Hexa)
ZWayIP:8083/ZWaveAPI/Run/SendData(2,[ 135, 1, 1 ]) (Decimal)
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 ACK
I’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?
UZB Long Range
Z-Wave.me
7
Posts
3
Posters
786
Views
3
Watching
-
I have tested the 700 series chip, not on a uzb but back on the vera and back then the controller API was not ready. Looking deeper and understanding how zwave works, I have come to the conclusion that in terms of range, the new 700 series will not show much benefit from changing the controller (It explains why silabs focused on device implementation rather than controller). Long range means stronger signal strength from the controller. It doesn't mean it can receive from devices further away. The range of your mesh is therefore much more dependent on the signal strength of the devices than it is on the one from the controller....
The new chip may reduce the number of hops close to the controller... but upgrading the controller alone won't do much. Upgrading the devices alone however will improve the range for the simple reason that the limitation is generally coming from the devices (especially battery powered ones) rather than the controller (unless you have a weak controller antenna setup which is not the case of the uzb). Also, in most setups your range limitations are at the edge of your mesh and your controller is supposed to be at the center of it. The network range will benefit most from upgrading the nodes at the edge.Food for thought... My testing showed nearly 0 benefit.
-
Always good to know a new UZB is coming.
Thanks for the information.Hopefully this will also solve the debacle of bad stick production batches which makes firmware updating a nightmare.
Other than that, to me it looks like we will have to wait for nodes which use the same LR chip to be able to fully benefit it's potential.
