Indeed!!! And the fact that you made the migration to zway through openLuup actually easier that it would be to the new platform made the decision a no brainer. Why wait for a hypothetical future platform when we can have a stable and scalable system now without the need to re-learn and make a ton of changes for no benefit?
You are absolutely right and I truly respect your work. I believe it’s a path for users that want to gain stability. I’ll probably shift to a similar solution soon, since I still have tardiness and queue problems and stability is always very fragile.
1 Like
Cant wait for the manual to be dummy proof :-).
1 Like
How dummy proof does it need to be? 
Feel free to comment on what I have already wrote.
The problem with dummies is that they are so damned inventive! 
C
2 Likes
Alright I made some more progress. Please provide feedbacks and questions.
In the meantime, I am donating 1x extrooted plus and 1x exrooted edge units to whoever wants them in the US. PM me if interested. I would just ask for the shipping cost.
1 Like
Wow nobody wants a free vera plus or edge with an attached SSD?
Also no feedback or question on the instruction write up?
Been continuing to run tests and minor improvements to the bridge while stuck home due to the virus. Hope everyone is well.
1 Like
Yeah, waiting out my 14 days after possible exposure in California while on business last week. I’m trying to get some work stuff taken care of and will look at the write-up when I can. Thank you again for doing this!
Yeah I cancelled my business trip to the bay area this week because of it…
It’s wandering off topic and I know you are local in Portland so … is it snowing here???
I’d love one, but I couldn’t use it and already have one 
As for the instructions, I’ll probably be migrating in the future, but other priorities right now 
C
1 Like
I’m based in Italy and, well, I’m on my 3rd week locked down and counting. I just redid my entire network with new switch, ordered new motorized internal roller shutters, and fixed my synology nas. Unfortunately I can’t call my electrician to fix a couple of things, but I’m busy. We have one more week locked down and I fear we may add at least two more, so I’ll probably embark on a similar project if my spare time continues to grow.
We’re ok since I live 50% of my time here and 50% in Milan where things are instead crazy. Home automation is helping to stay focused on other things for sure…
4 Likes
We had our first case in my town this week. It was a Policeman. I think they may of misdiagnosed, I think it’s swine flu,
Well, tomorrow after gardening I’ll have time to implement your virtual http sensors for sure
1 Like
Very poor indeed!
C
Both units are going to @LibraSun!! He will make much better use of them than I will have opportunity to.
5 Likes
I am on day 5 and while @akbooer is still working on refactoring the bridge, and I on my side have been adding a few bindings here and there (i.e reporting dead nodes, doorlock last trip, HEM report time, etc), I can see indeed that everything is fixed. The only problem I had from a sensor not unripping… I discovered was due to me having rebooted the z-way server while the sensor sent its untrip frame.
I am still having mental twitches and spasms from my traumatic experience with Vera to want to control things I probably don’t need to… frantically looking at logs, expecting things to have a delay or to not work a certain % of the time… but nothing.
I have been thinking of making my “untrip all sensors” scene work as z-way will not allow their virtual sensor devices to untrip through a command. But… Now I think it is likely completely unnecessary. I wrote a lot of code to workaround Vera’s failures which I can now remove.
As I am looking through logs, I am also learning new things… Not a trace of any Got CANs and… some old devices which I didn’t think had instant status now report them correctly. The got CAN is caused by the vera receiving a frame type it is not expecting and therefore deciding to shutdown its zwave API port of 0.1s. The problem is for the vera is that
- This is completely misdiagnosed. The switch is sending a data frame reporting its status while the vera is waiting for an ack frame in response to its command
- The vera responds in the worse possible way, by shutting down communication which is a strange habit the vera has to always take the only worse course of action than doing nothing: shutting down or reboot.
I am seeing a lot of my security class sensors updating their states and needing to exchange NONCE frames with the controller. This is where the NONCE_get flood from the vera comes from and again, the vera takes the only worse course of action than doing nothing: It blocks its command queue from sending any more commands, I am guessing in an attempt to quiet the network and get the NONCE report frame it was expecting. It does so for 20s or 2s and I haven’t figured out why and when it decides which. This is an attempt to prevent a race condition in the network. The problem is that it is never getting it because the secure class device is a battery powered sensor. It already sent it NONCE report frame and is asleep. That NONCE report frame was likely unexpected by the vera either because it shut down its communication due to a Got CAN or the vera was so slow to react that it was not yet expecting the NONCE frame and threw a got CAN.
Basic fundamental design principles vera is violating:
Never shutdown your coms with the serial API.
Never block the command queue while waiting for a frame. You can pace the commands out to say 1 command every 0.1 - 0.5s but never blocking it altogether.
When you have these, it will force you to deal with the got CAN appropriately and process these frames and figure out a better way to prevent race conditions.
3 Likes
Day 6 of this now blog like thread… And I took the liberty to change its title to make it more descriptive of what it is about.
All is well on z-way and the bridge for zwave. The only one thing which could potentially improve the bridge would be the implementation of async polling.
I was planning on keeping the zigbee network on the vera plus and see how well it fares while having the option of moving to home assistant. As if the vera was begging me to take it down it gave me another exit code 245 luup reload last night, the second one is about 1 week time. In itself, it isn’t a big problem anymore since it is only a zigbee controller connected through verabridge, hosting no plugin or scenes so it could be tolerated. But… why bother to maintain an additional piece of software in the system which I could move to a better stack and library which is already up and running (ZHA component of home assistant?)
The biggest challenge is that there is no bridge to home assistant equivalent to the vera bridge and the zway bridge. Home Assistant is also much more complex with many other device types rendering such a bridge practically impossible so… Given the fact that I have only a dozen of devices I decided to manually bind openLuup devices to their Home Assistant’s corresponding entities. This requires:
- Creating devices on openLuup and setting them up (as switches, dimmers, sensors etc)
- Adopting all the devices previously on vera to Home assistant and setting them up on Home assistant
- Creating scenes triggered by openLuup device actions to send a command to Home Assistant
- Creating automation on Home Assistant to trigger commands to openLuup to update their corresponding device status.
It’s not migration per say since zigbee networks cannot technically be migrated from one controller to another, it is re-creating the network and binding it to openluup manually. The good thing is that it is a lot of copy paste of short yaml and luup code but it is tedious and doable. I can provide instructions for people who would want to do this.
The gain is that I finally am rid of the vera software altogether and have a much better zigbee support (I can now add Tradfi or Hue and any other ZLL protocol and many other devices) with a more reliable platform… To be clear, I am still using the vera plus hardware, which is placed in a central location in the house, and sending both its zigbee port over IP to home assistant and the uzb dongle plugged into its usb port also over IP to z-way and the whole thing is controlled by openLuup.
I would not have done it this way for zwave because of the number of devices. For zigbee though I have 11 nodes and 35 resulting virtual devices. It’s already pretty tedious.
I agree it is not pain free. Any migration will involve some level of pain. The four questions in my mind to sway the decision are:
- How long are we waiting to wait? There are readily more stable platforms today.
- How much confidence do we have on the new platform? This is rather subjective but given the track record and the way this is coming. Mine is pretty low. I see no sign that the fundamental low level problems of the old have all been addressed and neither do I feel that they were even understood and most of the dev team is the same. Neither am I given the ability to test it and as I discovered, the zwave stack is not even finished yet so I have no idea what we are testing?
- How much pain am I willing to go through? As it stands, from all the documentations and directions I am seeing, it will be astronimically more painful to migrate to ezlo’s platform than to the openluup-zway combination.
- What benefits will I get from the new platform? For all the “love it” comments and new stuff being added, we, in the community have been doing them better more reliably and more computationally efficiently over the years. Yes they took more work and there is benefit from making them more accessible and user friendly but they won’t be new, exciting or more reliable. Overall, for my personal use, reducing the potential benefit to 0 or rather negative given the risks from immaturity above.
For me it was a no brainer…
To each his own - my glass is half full
Seriously, you have made immeasurable contributions to Vera and the community at large and I personally respect your decision to pursue alternatives. Your transition further reinforces my belief is that this community, at this very moment, is critical to the success or failure of the platform and as long as I am participating, I will do whatever I can to help ezlo succeed, otherwise I am wasting my time and theirs. In that spirit, if the day comes where I see it as you do, I will transition without looking back and in a manner that ensures that I don’t do anything that could chip away at ezlo’s future success.
3 Likes
I completely agree with you. This community is absolutely critical to the success of eZLO and we have to applaud and encourage the openness of the staff here. I too hope for their success. They just ran out of time for my specific use case. I don’t, by any stretch of the imagination, believe that the task is easy. I am not shutting the door to ever starting a new setup with this upcoming platform. For my current one however, I can’t afford the instability and the time spent on it anymore.
We are all very blessed to have contributors and testers like you!
1 Like