Thanks for the reply, the below seems to be the issue:
Callback execution error: TypeError: Cannot read property ‘error’ of undefined
at Function.http.request.error (automation/userModules/OpenHABConnector/index.js:403:107)
My setup is a RPI2 with the Razberry Board running z-wave. I then have a Ubuntu VM running Openhab. My Openhab is not on localhost per the logs rather http://192.168.80.2:8080, but I presume that is how it communicates?
Any ideas greatly appreciated. I started fresh yesterday with the Ubuntu VM. Considering doing the same with the RPI2 but seems excessive.
ZWay/RaZberry v2.3.6 (with the Shield on the Rasberry Pi 3)
OpenHAB Connector 0.1.7
But I have to restart my openHAB from time to time as it stops working after some days. But it isn’t quite working with newer openHAB-Snapshot versions.
I got the Errors only when I changed some things like:
item/thing-names in openHAB (are you linking them by hand or through the system? To do it by hand you have to disable the, how is it called, simple linking? switch in openHAB-PaperUI system preferences)
I think low battery in devices etc.
Perhaps it helps removing the connection between openHAB and ZWay and reestablish it (delete the configuration of the zway-binding and the openHAB-server in zway-openhab connector preferences).
But after this, of course, you have to reconfigure youre devices like you did it before.
I went ahead and installed Openhab2 on the Raspberry Pi that z-wave runs on (localhost). Z-Wave Openhab connector immediately works in this configuration.
What I couldn’t get to work was have the Openhab Connector work correctly with a remote Openhab2 instance
As @pathec didn’t respond in a VERY long time I’m thinking that he dropped this project…
I’m considering switching from Z-Way to Z-Wave binding… but… OMG!
Yes it seems so. My setup is working ok now. I have had to install OH2 on my “Slave” RPI2 that has the z-wave Daughter Board on it and the Openhab Connector works perfectly with this “localhost” setup with instant update to OH2.
I am now setting up MQTT event-bus to send everything from this slave z-wave device to my main instance of OH2. Things are looking much better with instant update vs the waiting 60 seconds previously waiting for the polling to kick in. I have ended up losing a heap of configuration after re-imaging everything but as this is the base of the new system, seems worth it… regular snapshots from here forward to backup.
I just upgraded to 2.2 STABLE and Z-Way is working normally
For the ones interested I applied the following steps (not sure that the approach to update makes any difference or the STABLE is different from SNAPSHOTs I was trying)
sudo apt-get remove openahb2
sudo apt-get update
sudo apt-get upgrade
sudo reboot
sudo apt-get install openhab2
sudo systemctl enable openhab2
sudo systemctl start openahb2
and, after waiting for the initial startup of openhab, now everything appears to run smoothly - including Z-Way
@Mihai_Badea motivated me to spend my Friday night to do the same, which seemed to work at first glance. But now, only a few hours later, the symptoms are the same like in the snapshot version.
Looking at the logs, you dont even sse, whats happening exactly, the thing handler timeout messages disappered, devices dont execute commands.
After a bundle:stop which took abput two minutes, the console log is flooded by all the notifications that had been stuck. Restarting the binding after another minute or two brings back functionality partly: switching a light from paper ui or a motion sensor both take 2-3 seconds from command to execution. the same command on the z-way instance directly is executed immediatey.
After a stop openhab2.service and start, items in Paper UI are only partly restored. Only a reboot of the RPi restores funtions completely for the next few hours (I guess).
What a frustrationg waste of time again.
In 2.1.0 everything worked like a charm for weeks without a reboot necessary. Either 2.2.0 is a not too stable version at all or the Z-Way Binding is not usable any more with > 2.1.0, the maintainer @pathec disappeared.
The WAF will go down to zero today, I see a lot of my investment in ZWave tech getting worthless…
I swapped to the zWave serial driver… You lose the ZWay server functionality & ability to run them on separate hosts, but gain a lot… Stability, the ability to differentiate between multiSensor channels, etc.
Over all, a disappointment, but at least there’s the choice… The zWave serial isn’t all good though… I also gained random 500 server errors from the REST interface, but it looks like it’s a known issue…
Dear @pathec
I just posted a topic on runtime section but after I found that the problem seems to be related to zway binding.
Are you using the old version of openhab? Did you planned any future release of your great binding?
I am still struggeling with the Z-Way server, which I really would like to keep instead of the OH Zwave Binding. But testing to replace the Z-Way Binding with MQTT showed me, that I am riding on a dead horse. The MQTT App in Z-Way does not work at all, maintainer does not reply. Z-Way Support doesn‘t either reply for my roadmap question concerning MQTT.
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.
