Another transition from Vera to OpenLuup And now to HASS - PerH

PerH · wrote on Sep 22, 2020, 5:00 PM

Thanks! I'll try later.. My system isn't doing anything important yet anyway.

PerH · wrote on Sep 22, 2020, 10:04 PM

No success on first attempt.. i'll have a new stab at this later.
Where does plugins store their tables? i see in the code that the plugin stores several tables somewhere?

akbooer · wrote on Sep 23, 2020, 6:56 AM

Yes, it’s the plugins which are the real issue here.

The multiple assignment in the above code, though, are entirely due to Vera’s very poor internal implementation of some features, which openLuup had to emulate.

It would be possible to edit the user_data.json file where all the information is stored between reloads.

PerH · wrote on Sep 28, 2020, 10:45 PM

Coming back to this, I found that the code actually did work! I didn't think so, as all the created devices was invisible, and said "no such device" in the device list in openluup.. 6 days later, all sensors are populated and functioning.

The UZB has now arrived, so i guess the next step is getting the z-wave stuff over.

PerH · wrote on Sep 30, 2020, 1:25 PM

Ok, so Z-way is now installed and GUI is working, but before I buy the (hopefully one-time?) license:
Is there other Open-source alternatives to get z-wave to openluup?
Is the device compatibility list better than vera? (can't seem to find it anywhere!)
will the altUI mesh-map work with z-way integration?

I found the demo license button now, but can't update the vendor list.. and i can't find the two devices i tested..

rafale77 · wrote on Sep 30, 2020, 2:02 PM

Seems like I can help on this:

The only open source z-wave library that I know of is... openzwave. It is what home-assistant, openhab and domoticz uses. It honestly is much better now than vera but not as good as z-way but is also undergoing significant development.
There is no device compatibility list because it is just compatible with zwave. All zwave devices should work. There is no custom gizmoing around configurations the way vera has done it. So yes device compatibility is limitless.
The mesh map could be made to work but does not at the moment. It is built off of the neighbor's list property which the bridge is not publishing from z-way at the moment. z-way UI has it's own neighbor mesh visualization.

The license is attached to the uzb itself and it is something I don't like. Is the uzb fails, you lose the license. It has not happen to me yet but I am really not a fan of this method that's why I got a couple of razberries as backup but their antenna is not nearly as good as the uzb and require a rPi.

PerH · wrote on Nov 2, 2020, 11:56 PM

Been busy with other projects, but as i'm quarantined, I got some time to play with this again:

Bought the lisence, to which the UZB status responded with "Device seems to be dead"... hmm..
After fiddling with some settings, I realized that it is working somewhat, I managed to add a NEO Coolcam switch to it.. At least 23% added..
I can actuate the switch, but the z-way UI can't seem to get that message for some reason?

So something is still wrong, where do I start?

The vendor list is still not updating in the "non-expert" UI, and the z-way bridge in openluup states 0 vdevs and 0 znodes..

Any help is appreciated!

rafale77 · wrote on Nov 3, 2020, 5:10 AM

For your switch it appears that you have not completed the interview (equivalent to the vera configuration). You probably want to go to the expertUI and finish that before you can see it in the automation UI.

The z-way bridge talks to the API corresponding to the automation UI so if you don't see the device there, you won't see it in openLuup either.

PerH · wrote on Nov 3, 2020, 9:55 AM

I tried that several times, and can see that the switch responds in the job cue.. the last attempts ended in 0%, so i asume that the problem isn't with the switch?

"Device is working properly"? with 0% on the interview?

PerH · wrote on Nov 3, 2020, 1:19 PM

It seems that the communication with the uzb stick is not correct, some things work, some things don't..

I'm leaning towards a full reset of this thing now, mabye it'll go smoother the second time..
is all openluup settings and data contained in the /cmh-ludl/?

Mabye ubuntu is a better core for this setup than Debian Buster?

akbooer · wrote on Nov 3, 2020, 1:46 PM

Everything should be in the user_data.json file, but it will get rebuilt on restart from the ZWay API.

rafale77 · wrote on Nov 3, 2020, 2:40 PM

@PerH, Don't be too fast at resetting things. This is not a vera. It is possible that your device is not responding as expected. I often had to manually interview devices by calling the command classes one by one. Click on the "view interview result" and you should see the list of command classes. You can then see which ones are missing.

PerH · wrote on Nov 3, 2020, 2:49 PM

Hehe, OK.
I'm still finding it odd that my system says that the Z-Way controller is reported as "Dead" in the device list though, that makes me think that the device or communication is not going well..
Despite of this, i can actuate the switch even if the expert panel says i'm not.

some strange callback errors in the log:

[2020-11-03 14:47:06.133] [I] [z-way] Job 0x13 (SwitchBinary Get): Delivered
[2020-11-03 14:47:06.133] [D] [z-way] SendData Response with callback 0x13 received: received by recipient
[2020-11-03 14:47:06.133] [D] [z-way] SETDATA devices.6.data.lastSendInternal = **********
[2020-11-03 14:47:06.133] [D] [z-way] SETDATA devices.6.data.lastSend = 389830 (0x0005f2c6)
[2020-11-03 14:47:06.133] [D] [z-way] Job 0x13 (SwitchBinary Get): success
[2020-11-03 14:47:06.133] [I] [z-way] Waiting for job reply: SwitchBinary Get
[2020-11-03 14:47:06.153] [D] [z-way] RECEIVED: ( 01 0C 00 A8 00 01 06 03 25 03 00 00 C9 B0 )
[2020-11-03 14:47:06.153] [D] [z-way] SENT ACK
[2020-11-03 14:47:06.153] [W] [z-way] No job of class 0xa8 is waiting for callback 0x00
[2020-11-03 14:47:06.153] [I] [z-way] Unhandled callback for function 0x00
[2020-11-03 14:47:06.153] [I] [z-way] Removing job: Unknown function class

So, before I look at the devices, i need to find out why the server and stick communication is throwing errors..

PerH · wrote on Nov 3, 2020, 2:51 PM

One other thing, sometimes (i think on some reset of something), the port address to the stick changes from "ttyACM0" to "ttyACM1" for some anoying reason.. any ideas?

PerH · wrote on Nov 3, 2020, 3:21 PM

Result in the log of trying the "basic set" interview manually:

[2020-11-03 15:18:46.829] [I] [z-way] Adding job: Basic Get
[2020-11-03 15:18:46.830] [D] [z-way] SENDING (cb 0x3c): ( 01 09 00 13 06 02 20 02 25 3C DA )
[2020-11-03 15:18:46.832] [D] [z-way] RECEIVED ACK
[2020-11-03 15:18:46.840] [D] [z-way] RECEIVED: ( 01 04 01 13 01 E8 )
[2020-11-03 15:18:46.840] [D] [z-way] SENT ACK
[2020-11-03 15:18:46.840] [D] [z-way] Delivered to Z-Wave stack
[2020-11-03 15:18:46.860] [D] [z-way] RECEIVED: ( 01 05 00 13 3C 00 D5 )
[2020-11-03 15:18:46.860] [D] [z-way] SENT ACK
[2020-11-03 15:18:46.861] [I] [z-way] Job 0x13 (Basic Get): Delivered
[2020-11-03 15:18:46.861] [D] [z-way] SendData Response with callback 0x3c received: received by recipient
[2020-11-03 15:18:46.861] [D] [z-way] SETDATA devices.6.data.lastSendInternal = **********
[2020-11-03 15:18:46.861] [D] [z-way] SETDATA devices.6.data.lastSend = 56446 (0x0000dc7e)
[2020-11-03 15:18:46.861] [D] [z-way] Job 0x13 (Basic Get): success
[2020-11-03 15:18:46.861] [I] [z-way] Waiting for job reply: Basic Get
[2020-11-03 15:18:46.874] [D] [z-way] RECEIVED: ( 01 0C 00 A8 00 01 06 03 20 03 00 00 C7 BB )
[2020-11-03 15:18:46.874] [D] [z-way] SENT ACK
[2020-11-03 15:18:46.874] [W] [z-way] No job of class 0xa8 is waiting for callback 0x00
[2020-11-03 15:18:46.874] [I] [z-way] Unhandled callback for function 0x00
[2020-11-03 15:18:46.874] [I] [z-way] Removing job: Unknown function class
[2020-11-03 15:18:48.987] [W] [z-way] Reply not received before timeout for job (Basic Get)

To me, it looks like the unit is responding, and the server is having a "senior moment".. ?

rafale77 · wrote on Nov 3, 2020, 5:00 PM

Hmm this is indeed a bit strange.
On the port address changing... it is a common linux problem, widely reported for many devices.
linux recreates and iterates another id for a usb device when it resets. I had this problem even with the vera when I ran it off of a usb dongle. The solution to this is to use another path to the port:

run
ls /dev/serial/by-id

and find the id of the uzb. Mine looks like this:
usb-0658_0200-if00 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2211489-if00

I have both a uzb and a conbee stick plugged into my mini PC. You can then use this port /dev/serial/by-id/usb-xxxx_xxxx-xxxx
instead of /dev/ttyACMn.

For your other issue, you might be right. Maybe reset then as I am have never seen this behavior before.

PerH · wrote on Nov 3, 2020, 5:58 PM

Thanks, I did that now, so one issue less i guess.

One thing i've read is that z-way needs a "V8 engine" called libv8 (3.24.37). This is as far as i've found not native in Debian buster, can this be whats missing here?

PerH · wrote on Nov 4, 2020, 9:25 AM

So, the resolution to the recent errors was that the UZB Stick was set up with "Bridge" firmware! to fix, go to ExpertUI - Network - Control - Firmware - Switch to "Normal" Firmware.
I may have been blinded by the "F**k, nothing i try works", but i think this detail could be more visible to beginners in some way, i.e. a small pop-up message when you try to add sensors in a-way (which requires normal mode FW).. I will pitch this to the z-way guys.

Onwards!

PerH · wrote on Nov 5, 2020, 10:48 AM

Rebooted the box, and now Openluup won't start. (this probably relates to my appstore-issues as well)
The issue is the Libcurl.so.4.

● openluup.service - openLuup and AltUI Server for Vera 3
   Loaded: bad-setting (Reason: Unit openluup.service has a bad unit file setting.)
   Active: inactive (dead)

Nov 05 10:26:21 Chromebox systemd[1]: /etc/systemd/system/openluup.service:9: Executable "curl" not found in path "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
per@Chromebox:/etc/cmh-ludl$ curl
curl: /lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by curl)

I'v done the stuff you need to get libcurl 3 going for z-way, and probably f**ked it up somehow.
Can anyone help me reset this with some well chosen command line words?

PerH · wrote on Nov 5, 2020, 12:43 PM

Did this:
@rafale77 said in z-way-server ubuntu install:

@PerH

The problem is that libcurl3 is not in the standard repo you have listed.
assuming you are on ubuntu download it from here:

Ubuntu – Error

You need to pick from the correct platform.
wget --url you can paste from the link above--

i.e
wget http://no.archive.ubuntu.com/ubuntu/pool/universe/c/curl3/libcurl3_7.58.0-2ubuntu2_amd64.deb
downloading from the norwegian mirror for x64

Then run
dpkg -i libcurl3_7.58.0-2ubuntu2_amd64.deb
might need sudo authority to install.

Edit: Another idiot way to do it is to not install libcurl3 at all and instead create a symbolic link for libcurl3 to call libcurl4 (That's how I am running mine )
sudo ln -s /usr/local/x86_64-linux-gnu/libcurl-gnutls.so.4 /usr/local/x86_64-linux-gnu/libcurl-gnutls.so.3

sudo ln -s /usr/local/x86_64-linux-gnu/libcurl.so.4 /usr/local/x86_64-linux-gnu/libcurl.so.3
Note that you will need to find where your libcurl library was installed. I just gave you the ubuntu location.

and

apt install curl
systemctl disable openluup.service
systemctl enable openluup.service
systemctl start openluup.service

up and running again. Now the appstore is OK too, commencing attempt 2 on z-way bridge.

Seeking Advice:

15+ Smart Home Automation Ideas from Pros

Finally gave up on my Ezlo Plus

Another transition from Vera to OpenLuup And now to HASS - PerH

Half-way migration from Vera

My Home Automation Story

My migration from Vera, or what I did on my holidays

Not so much a blog

My Wandering

This is me

My Home Automation Setup...

Another transition from Vera to OpenLuup And now to HASS - PerH

Recent Topics