Java Runtime Environment: OpenJDK 64-Bit Server VM Zulu11.43+100-CA (build 11.0.9.1+1-LTS, mixed mode)
openHAB version: 3.2
I’m moving from my production OH2 server running on Beaglebone Black to OH3 on an Odroid C4 and I’m running into some basic issues. I think I’m just missing a step.
Before I get into my specific issues I would be remiss if I didn’t address some important issues in this move.
Armbian vs. native Odroid image… I choose Armbian because the official Odroid image did not allow me to install a 32 bit java jdk. Numerous methodologies are posted in regards to this but at the end of the day none of them work. Additionally, the OS becomes problematic because of the kernel revision be greater that 255 in the lastest office Odroid OS (ubuntu-20.04-4.9-minimal-odroid-c4-hc4-20210906.img). At some point this prevented me from being able to try and get 32 bit apps running because I could not update the system. That said, Armbian via armbian-config actually installs the 64 bit version so I might run into issues anyway since 64-bit java apparently might be problematic.
Issues with early Aeotect z-stcks and cdc_acm support… I really hope this saves someone else some time. If you have a Gen 5 stick and you plug it into a USB3 port and nothing happens, you probably need to get a new z-stick. There is a hardware issue with the original Gen 5 sticks (see AEOTEC USB Zwave module not creating /dev/ttyACM0 · Issue #3027 · raspberrypi/linux · GitHub) which only allows them to [maybe] work in USB2 ports. You can use the OTG port on the C4 but that just add more “stuff” to your build. If you purchase the Gen 5+ stick (you’ll see it say it works with Rpi 4 hardware) you’ll be fine. This one does indeed at least create /dev/ttyACM0 when I plug it in.
This leads to my issue. I restored my OH2 config to this new OH3 system. All I have is tp-link and z-ware devices. The tp-link devices appears to work (I played with the brightness control of one bulb) but the z-wave items are not coming back. As I said, the /dev/ttyACM0 device is now available but I do not see anything in the inbox for the z-wave controller nor do I see my z-wave devices when I sort things by bindings. I have fully rebooted the hardware and then also removed and re-added the z-ware add-on (with a restart of openhab afterwords). Still no joy.
Did I miss something in regards to how to bring z-stick online in OH3? I admit, I haven’t take a deep dive into the changes between the versions so I’m hoping this issue is something I was un-aware of. I don’t remember having to do anything special to detect the z-stick in OH2 but it has been awhile.
I’m not familiar with your hardware (I have rpi4). Are there any log messages? If you are loading the zwave binding in addons, you need the karaf feature:install openhab-serial-transport. If you installed from the UI, that is done for you, so is not the problem.
The events file is blank but /var/log/openhab/openhab.log some benign errors like:
2022-01-28 19:48:53.667 [WARN ] [.transport.servlet.ServletController] - Can’t find the request for http://192.168.27.43:8080/rest/addons/services’s Observer
2022-01-28 19:49:05.819 [WARN ] [org.apache.felix.fileinstall ] - /usr/share/openhab2/addons does not exist, please create it.
2022-01-28 19:49:05.862 [ERROR] [org.apache.felix.fileinstall ] - Cannot create folder /var/lib/openhab2/tmp/bundles. Is the folder write-protected?
2022-01-28 19:49:05.869 [ERROR] [org.apache.felix.configadmin ] - [org.osgi.service.cm.ManagedServiceFactory, id=44, bundle=17/mvn:org.apache.felix/org.apache.felix
.fileinstall/3.7.2]: Unexpected problem updating configuration org.apache.felix.fileinstall.8593dc81-e877-4e01-b232-ce8ede9ebd77
java.lang.RuntimeException: Cannot create folder: /var/lib/openhab2/tmp/bundles
I say benign because I’m assuming that is an artifact from restoring an OH2 config to an OH3 server but I can’t see how that would prevent OH3 from doing things properly. I did add the z-wave plug in from the gui. Is there are way I can check to see if the openhab-serial-transport is loaded from the cli?
If you loaded zwave from the UI, you are ok. You could check with feature:list or maybe bundle:list in openhab-cli.
The concern I see is that OH3 eliminated openhab2 folders. Everything is openhab folders now. You may want to review the release notes on breaking changes between OH2 and OH3. It could be the problem. I’m surprised anything works to be honest.
openhab-binding-zwave │ 3.2.0 │ x │ Started │ openhab-addons-3.2.0 │ Z-Wave Binding
but I don’t see a line for openhab-serial-transport.
When I do, feature:install openhab- there is no openhab-serial-transport. There is a openhab-binding-serial but I don’t think you mean that (and that is not loaded on my 2.5 server).
When I do bundle:list…
270 │ Active │ 80 │ 3.2.0 │ openHAB Add-ons :: Bundles :: ZWave Binding
271 │ Active │ 80 │ 3.2.0 │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery
272 │ Active │ 80 │ 3.2.0 │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery for Linux using sysfs scanning
273 │ Active │ 80 │ 3.2.0 │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery using ser2net mDNS scanning
274 │ Active │ 80 │ 3.2.0 │ openHAB Core :: Bundles :: Configuration Serial
275 │ Active │ 80 │ 3.2.0 │ openHAB Core :: Bundles :: Serial Transport
276 │ Active │ 80 │ 3.2.0 │ openHAB Core :: Bundles :: Serial Transport for RXTX
277 │ Active │ 80 │ 3.2.0 │ openHAB Core :: Bundles :: Serial Transport for RFC2217
Which I think is what you were referring too. That looks the same on my 2.5 server (minus the bundle for 1.x compatibility)
Second I did refresh my memory use feature:list
I get (among a lot of other stuff)
openhab-transport-mqtt │ 3.2.0 │ │ Started │ distro-3.2.0 │ MQTT Transport
openhab-transport-serial │ 3.2.0 │ x │ Started │ distro-3.2.0 │ Serial Transport
openhab-transport-upnp │ 3.2.0 │ │ Uninstalled │ distro-3.2.0 │ UPnP Transport
However, if it isn’t there, just use feature:install
Bob
I purged the openhab and re-added it to start clean and in doing that, I found out what I missed. Once the add-ons are installed and you go to “Things”. There is a + sign in the bottom right. I was going to the “Inbox” under “Settings” expecting to see things there to accept like in 2.5. So this was just user error on my part. Once I did that I could set up the new z-stick. Manually moving the files from the old OH2 /etc/ paths to the OH3 /etc/ went fine as well. That made adding back all the the tp-link stuff easier (the items in my items file were automatically discovered so I was able to add them all at once). All the z-wave stuff items are showing null as before but that is because I need to find a way to move those from the current stick to this one. That’s probably an Aeotec question (unless that question has been discussed here already- I haven’t searched yet).
Also, I do not think you do need (i.e. it is not marked “Required”) the “openhab-transport-serial” addon for the Aeotec z-stick…
openhab-transport-coap │ 3.2.0 │ │ Uninstalled │ distro-3.2.0 │ CoAP Transport
openhab-transport-http │ 3.2.0 │ │ Started │ distro-3.2.0 │ HTTP Transport
openhab-transport-mdns │ 3.2.0 │ │ Started │ distro-3.2.0 │ mDNS Transport
openhab-transport-modbus │ 3.2.0 │ │ Uninstalled │ distro-3.2.0 │ Modbus Transport
openhab-transport-mqtt │ 3.2.0 │ │ Uninstalled │ distro-3.2.0 │ MQTT Transport
openhab-transport-serial │ 3.2.0 │ │ Started │ distro-3.2.0 │ Serial Transport
openhab-transport-upnp │ 3.2.0 │ │ Uninstalled │ distro-3.2.0 │ UPnP Transport
I do not see what would be different about the rpi in this case but that addon is not running on my current Beaglebone Black system nor the Odroid C4 that is going to be the new system. The addon is simply started.
Interesting re: openhab-transport-serial. Must just be a RPi thing.
Depending on the age of the zstick there is either the Silabs PC controller or an older Aeotec Zstick gen 5 backup tool. one uses a zip file (newer) and the older a .bin to transfer NVM information between sticks.
So, did you get this going? I am debating to move from Windows to Odroid instead of Raspberry Pi 4 because of the chip shortage… the z-stick works fine on Windows, but if it turns out to be incompatible with Odroid and/or Pi, I may not try to move…
Possible confusion. The older Aeotec Z-stick will not work in the Rpi4 without being put into an USB2 hub (does not have to be powered). I do not know about the Odroid, but it sounds like (from the very first post in this thread item 2.) it is possible using the OTG port. The newer Aeotec Z-stick has no usability problems (AFAIK)
Apologies for the late response but yes per my Jan 29th post I was good on Odriod C4 with OH3. The biggest headache was moving the z-wave devices because the C4 needed the Gen 5+ model (unless you use the OTG port). To make matters a bit more complicated, the Aeotec software needed to dump and restore is Windows only and does NOT work under virtualization.
Entry devices like locks must be excluded BEFORE you backup the stick as well. This is easy to do with the Aeotec stick since it is powered and you can take the stick to those devices because they absolutely need to be “close” during the procedure.
Other than that, OH3 screams on the C4- coming from the Beaglebone Black though, most everything would I think I don’t reget the hardware move at all and I would definitely recommend the C4.
I don’t reget the hardware move at all and I would definitely recommend the C4.