I’ still having trouble with my z-way-server, it is too slow after upgrading to OpenHAB 2.2.
But I managed to make it a bit faster by clearing the cache and tmp folders for openHAB.
Try this
Stop openHAB
Empty the folder /var/lib/openhab2/tmp - do not delete the folder itself
Empty the folder /var/lib/openhab2/cache- do not delete the folder itself
This made my connection between OpenHAB and Z-way-server a bit faster, but still not as fast as it should be.
So after this I started looking at the MQTT-app of Z-Way. I got it installed and working, but not sure if it sends data on enough values/items to be used standalone.
To install it i used the beta-version (adding the “key” mqtt_beta i the settings for the appstore)
There are some problems with the mqtt-app it seems, it does sometimes disconnect without managing to reconnect.
I’ll see if I have time to look into it and improve it as it seems like the Z-Way-binding will not be debugged and fixed by the maintainer.
Let me know how far you got to install the MQTT-app in Z-Way, and what errormessages was shown in the Z-Way-log.
Could you please explain why you do think this is an Z-way-binding-problem?
I did you upgrade my OpenHAB to 2.2, without updating my Z-Way-binding (Using a 2.0-SNAPSHOT).
This did not work properly, it is waaaay to slow. Then I upgraded the binding to 2.2, but no changes was seen.
I tried to stop the z-way binding using the openhab console.
In the same moment, I checked the “top” command in another linux console. The CPU use decreased a lot.
Ok, I’ll keep looking for that same behaviour on my machines.
Seems like the Z-Way-binding does a lot of thing all the time. It seems to discover servers and items even though they are already found.
Do you have the link to the topic you posted?
Hi, @stein_tore_tosse, thanks for the advice, will check that later this weekend.
Concerning the MQTT App, I see constant connects and disconnects, will provide logs this weekend.
I am not sure, but Z-Way outbound publishing seems to work, but inbound subscription doesn’t. I will validate that again.
My experience with the Z-way-binding after upgrade is that the Z-way-server sends updates to openhab, and this work, as you say, as it has before.
The problem is the change of an item in OpenHAB, it takes a long time before openhab even tries to send the data to the z-way-server.
The z-way-server itself is still quick and for every release more and more stable.
I had the same problem with the MQTT, had to restart the z-way-server to get it working again. I’ll check the code and see if I can fix it.
I have similar problems with Z-Way and Openhab bindings. Upon examination, i found the CPU increases the load until the openhab becomes slow and at least stops after a number of hours.
The more Z-wave units in network - the faster the CPU load increase.
I’ve solved the problem of a “work-around” using 1.x file for z-way server configuration in (things/zway.things).
Then i overwrite zway.things file every 6 hours with crontab. The OpenHab will update all things and CPU goes down again. (Se the red mark in picture)
Something seems to be buffed in openhab but I have not managed to find what it depends on.
I’m currently working on a solution about the Z-Way binding trouble. During the last days I think I identified the code where it starts to slow down.
I currently have a fixed binding running on my PI and if the system is not slowing down anymore I can release a new binding this weekend. But I can’t promise anything!
I can give a feedback tomorrow because normally the system starts to slow down after a few hours. Let’s cross fingers that the solution works…
I spent some time in the substitution of the Z-Way binding.
First I thought, that the MQTT App in Z-Way is unusable, too, but I have to admit, that it now runs like a charm.
Since my OH 2.3 snapshot and Mosquitto run on a NUC and Z-Way runs on a RPi colocated with OH 2.1 stable, after a reboot of the RPi I have to stop and start Z-Way again. After that it’s stable for more than 3 days now. I have “migrated” 7 rollershutters, 6 switches and 9 thermstats.
Althougt it was a lot of work and a trial and error learning curve, I am happy with it now.
It feels like, commands are executed with far less latency.
So, the connection between OH 2.1 and OH 2.3 is using MQTT?
Would you care to describe in more detail? A little step-by-step, if it’s possible…
It might be a workaround to our zway problems in 2.2
Both instances of OH, one WAFed production instance (2.1 stable) and one experimental (2.3 snapshot) use Z-Way as their Z-Wave Stack. While the production instance is connected over the Z-Way binding 2.1.0, the other instance is connected over MQTT using Mosquitto as the broker and the MQTT App within Z-Way. Both instances talk to the same hardware over different protocols and have their own items. Rules are the same, redundant on both instances. Does that answer your question @Mihai_Badea?
Yes, @Schnicki, it’s quite interesting…
Actually, with the MQTT app on z-way-server we could ditch the ZWay binding altogether.
As you said it will be a lot of work, on MQTT app you have to add each device by hand…
Hi
the binding seems to be working without slowing down. After about 24h testing responsiveness is the same as after starting.
I also improved latency of the binding and reduced the response time for commands from about 0.5s to about 0.1s at the improved binding.
So please feel free to test the new binding!
(Sorry I found no other way to share this easily… )
So the binding is a quick build and shall help testing the change. So on DEBUG level of the binding you find a " Handeling of command tooks xxx seconds" line to identify how fast the command is handled. So feel free to give feedback about your times.
Also the system usage of the CPU and RAM does not change over time:
Just for completion, I’ve wrote to Patrick (the original developer of the binding) and he said that he will take a closer look to the problem next week.
Thank you for the feedback. I also had no issues during the last days. So I will see that I will push the change to OpenHab if I have build a clean version of the binding.
