Cannot initialize controller, but I didn't make any changes, the /dev/serial/by-id shows the same path as before... #7398
Comments
|
Update: I used image tag 9.26 and it works again, so definitely not an issue with my controller or setup, it's a problem in the latest images. |
|
I am getting the exact same error. Restarting container, using different USB port, restarting the system - nothing fixes the error |
|
also my Aeotec USB stick was recognized anymore. I did a restart of my docker, replugged the USB stick but nothing works. When I did recreate the image I've got everything back online. Not sure what the root cause was in my case. |
|
Same error message as OP as of 12:00 CT. Controller: Aeotec z-stick 7 plus Rollback to 9.26 fixed issue |
|
Same issue here using a HUSBZB-1 controller using 9.27.1 Reverting to 9.26.0 fixed it. |
|
Please make a driver log, loglevel |
|
cc @AlCalzone seems this issue is still relevant with 9.27.1 |
|
If this is still happening with 9.27.1, I definitely need to see driver logs. Side note: IMO it seems a bit negligent to auto-update critical infrastructure, e.g. when doors cannot be opened without it working |
|
Just tested again, with a fresh pull of 9.27.1. Works fine for me, with UZB 3 (500 series), Aeotec Z-Stick 7 (700 series) and Zooz ZSt39 (800 series) controllers. |
|
Also working again with a fresh pull of 9.27.0 |
|
@Majestic7979 can you double check if pulling 9.27.2 (latest version) solves your issue? |
|
Confirmed that 9.27.2 is also working for me, but using the |
|
@robertsLando Any idea what's going on with the tag? |
|
I checked on https://hub.docker.com/r/zwavejs/zwave-js-ui/tags and the shas of 9.27.2 match latest so sincerely I have no clue |
|
I'm still getting this with a fresh 9.27.2 pull: A downgrade to 9.25.0 restores it immediately. (9.26.0 is also broken.) |
|
Coulds you paste full logs (application logs AND driver logs on loglevel debug) please? |
|
I've set the driver to debug and restarted, but it did not add the driver logs. I had to point it at a file before I could get anything: |
I think you need to run in raw device mode ( |
|
That was it! Thanks! If anyone else hits this with ser2sock, the docker container entrypoint is a mess. (Even on my fork.) The fix is to force command: /usr/local/bin/ser2sock
args: ["-0","-s","/dev/ttyUSB0","-b","115200"] |
AlCalzone
added
Tech Support 📞
I am hesitant to do this due to recovering from a health issue at the moment and must have the ability to unlock the door at all times for emergency purposes, so will leave on the old tag 9.26 for now and will close the issue once I've had a chance to test. But I am scared of using zwavejs as my zwave network manager now because the Aeotec stick is probably the most commonly used stick out there and I sincerely find it shocking that something was distributed without checking that the stick driver is loaded correctly. This could have caused a critical emergency situation in my case, I am not over-reacting just to make sure that my comment is understood. If a door lock (Conexis L2/L1) that is purely eletronic and has no key failsafe to open cannot be unlocked because ZwaveJS has a fault, it could mean a death situation. I implore the developers to please test with the most common sticks before releasing. I trusted that a Zwave server would do at least the most basic checks which is "does the stick driver load up", clearly I was wrong for giving the project this level of trust and that's on me. But I think users are being reasonable to expect the basics to work, no? Open Source or Free, or not, it doesn't matter, if this is in the hands of the public there should be some responsibility toward those users being safe from critical bugs like this one that could disable safety features. Once trust is broken it's only a matter of time until users abandone a product and the project dies off, so it's in everyone's interest to play nice. Having said the above I want to express my gratitude for each and every person writing code for this project, you are truly appreciated, I mean that! If all of you writing code could please do basic checks in the future to protect at least those of us who are more vulnerable then you'd be doing a really nice thing indeed. Thanks. |
|
@Majestic7979 We completely understand that and we are sorry for any inconvenience, we do our best every day to keep everything working as expected, sometimes there could be some unexpected issues (companies like Google Meta Microsoft have them as well) but, in most cases, we fix them in a few hours especially if they are bad 🙏🏼 |
Just to be clear, this was not an issue with stick incompatibility. All sticks speak the same protocol, and there are actually hundreds of tests that use this, which all passed. The main issue was that I switched the way binary data is parsed to a more modern implementation. Strangely, this more modern implementation is missing support for the very basic ASCII encoding, unless the Node.js runtime on that system was compiled with full internationalization support. To be honest, the possibility of this didn't even cross my mind. And of course, all development machines, as well as the automated testing on GitHub were using runtimes with full internationalization support. So this issue was never noticed until it happened in production. The second issue had to do with how this library is bundled downstream. Even though it is tested here that the released packages are valid, bundling them in that specific way broke at runtime, but only when using Docker, not when running Z-Wave JS UI directly (which I also did extensively). That said, I'll talk to @robertsLando to see how we can do at least a basic sanity check of the Docker images on CI before releasing them. On a more personal note: You must be very trusting in technology to install such a lock. For me, everything basic like lights, locks, etc. MUST have a physical fallback to control it. I wouldn't dare to install such a lock. |
Thank you very much for your polite and detailed reply,as well as to @robertsLando, you guys are great, truly! Unfortunately it is a tradeoff, I trust Yale/Assa Abloy products, I am actually one of their beta testers (I use beta versions on my back lock which isn't critical and strive to provide useful feedback so they can make their product as good as possible). I have used this lock extensively for years without issues, it is indeed very reliable, furthermore mechanical locks can fail, too, so there is always a risk. This is why @robertsLando mentioned that other companies have bugs... I fully agree and did not intend to make anybody feel blamed or guilty, it can happen and happened, it was a user's plight to improve further and check more thoroughly, with a "lessons learned" mindset, and not a critical mindset which only hurts everyone in the process and is unproductive. The fact is I truly depend on your code and it has benefitted me in so many ways greatly, I cannot find words to thank you guys doing this for free and even listening to feedback, I hope it was not received harshly, it was a humble request to ask for more attention during the checks to ensure it is as safe to use as possible. Your product is invaluable to me and I am truly grateful for your time and effort in developing this product. Thank you for fixing it quickly. I have not yet updated, for fear that it might happen again, but at some point I will have to, if only to keep up with requirements, and any issuess I'll report back. Please accept my sincere apology if this has made you feel bad, it was never my intention. |
|
No offense taken! To be honest, these latest 14.x releases have been more bumpy than I'd like. |
I'm glad to know that my message didn't cause any offence. I hope your future releases give you more satisfaction. I'll try to upgrade my server now and see what happens :) |
|
Pleased to report that tag 9.27.7 loaded just fine, thank you! |
Checklist
Deploy method
Docker
Z-Wave JS UI version
See bug description
ZwaveJS version
See bug description
Describe the bug
zwave-js-ui: 9.27.0.f3c4ac5
zwave-js: 14.3.1
home id: undefined
home hex: undefined
All was working at least until yesterday morning when I last used the door from outside, my door lock is z-wave, that's how I know it was fine at least up to yesterday. Today my housemate was locked out, door lock would not respond, I checked zwavejsui and it had this error:
I navigated to /dev/serial/by-id and the stick is recognized. I checked my docker CLI to ensure it was fine, and it was. I have my container auto-update itself via Watchtower, so the only thing that may have changed from yesterday to today is the zwavejsui version, and I believe this is the issue because upon logging in I received the usual "what's new" popup.
So whatever you did on the latest update as of this post, broke my Aeotec stick. When I say broke, don't worry I don't mean you killed it. I'm just saying it is not working. I will now try to use image tag to downgrade and see if it works again, will update this if it does. Otherwise please be aware it's non-functional and thankfully I was inside to open the door otherwise we'd have no way to get in and would have to break the door! So please treat this urgently as it may affect others, for instance it would be catastrophic if there was a fire and their lock was not operational because the latest update fubar'd something.
Thanks for reading my report, I appreciate your effort in making this software available!
To Reproduce
Not applicable
Expected behavior
Not break the driver...
Additional context
No response
The text was updated successfully, but these errors were encountered: