Longtime Vera user, new Ezlo user. Just set up my new Ezlo at our summer home. Simple ZWave network of 6 light controls and two battery handhelds (Aeon Minimote and GoControl WA00Z-1). Eight ZWave devices in total.
Created a few scenes including one for each of all on and all off.
I am finding the scene execution is unreliable. Often one or two of the end devices doesn’t get turned on in an all on scene but if I run it a second time it tends to get the rogue nodes. Same goes on an all off scene. Doesn’t always shut down everything on first try but tends to after the second.
This NEVER happened with Vera. There was enough handshaking with the node that if a node didn’t turn off it tried again. So in porting software to EZLO you seem to have lost the fundamental handshaking needed. It not a crisis for a table lamp but some people use Vera/EZlo for more critical applications and you need to be sure the action was faithfully executed.
I also notice the ZWave network is quite slow. I only control 6 devices. Sometimes its fast other times large delays. In my main home I control over 50 devices. I’m still with Vera Plus at main home but getting ready to move over to Ezlo there. I can’t have slow and unreliable ZWave with a 50+ element network.
So there are some bugs and/or missing error legs to be added to the ZWave/Scene execution software in Ezlo. Happy to make send traces or anything to help zero in on the problem. Vera was very solid with ZWave control, we can’t move backwards… This is must fix stuff.
With Ezlo, we brought in the “Multi Casting” capability in Zwave. This did not exist in Vera previously.
We suspect Multi Casting is used in your case and zwave protocol might have issues. (Multi Casting removes the Pop Corn effect when lets say turning 10 lights on at the same time etc)…
Team is informed and they should be in touch with you to investigate.
OK I’ll wait to hear. To be clear though my scenes don’t use an all on or all off command of any sort. I just separately list the 6 unique devices under the action section. I name the scenes “all on” and “all off” but that isn’t some inherent ZWave or Ezlo function.
Hopefully multi-casting has equally as strong handshaking as the prior (Unicast?) scheme for confirmation of state. Many folks have come to appreciate Vera’s solid ZWave performance and that needs to continue in Ezlo.
My application isn’t mission critical yet so I can live with this while you figure out how to harden it better.
CuriousB
you are sure right about scenes not working correctly I have an All OFF scene that has not worked yet
Also many of my scenes are time related but some work some don’t.
EZLO has been in business long enough now that these type of errors should not happen I am sending my unit back because of the unreliability of the overall unit.
I have scenes that I can not edit because if I make a simply change like the time of execution the scene will not save.
But if I great a scene in the Vera App it has features for a device that the Ezlogic does not even show.
I sure hope if Ezlo wants more individuals to purchase or ex Vera people to change over, they need to seriously update these problems and get their Web App working correctly and add the features that Vera had. Don’t know why if they bought out Vera why didn’t the buy rights to the software Vera used especially the operating core and all that went with it.
We appreciate your comments. We can check your controller and continue creating a ticket for your particular situation. Customers are our priority. I’ll do my best to help you with your situation.
There is a logic issue with the “Date Triggers”…our devs are aware of it…(one of the fields are not handled properly between the UI and the firmware)…So some Date Triggers might have an issue as a result…
should be fixed very soon though.
I would hang in there. Expecting Vera UI7 code stability for Ezlo isn’t a fair expectation this early in Ezlo’s lifecycle. Software drops improve incrementally. If Ezlo were quiet and not issuing code updates I’d see cause for concern but I see the opposite. They are active addressing issues here on the forum, via PMs, as well as periodic code drops.
I am giving them benefit of the doubt. Let’s see how they progress.
Well normally I would agree but they did buy the company and that comp[any was far advanced for where Ezlo is after 3 years so you wait and see I am returning mine and might come back later .
But right now they have put scenes in my controller that has adversely affect the operation of the few scenes I had working so not sure what they are resolving I wish to go forward not backward.
So it has taken over 4 days so far to try to get RMA from them and that is not a good thing either
I have found recently that scenes can have problems if you launch a new scene while the prior scene is still completing if both scenes operate on some of the same device(s). If I delay and let the first scene complete and wait a few seconds I seldom (never?) get this problem. Not sure what is going on but as a practical matter I won’t run scenes in tight cascade typically. To be sure scene execution needs to be rock solid though, it can’t be an “attempt” as it appears now. I suspect there is a logical reason for this and a bug fix or error trap will clear this up.
My concern is once I move my larger Zwave network over to Ezlo (50+ devices) an all off/all on scene operates on many nodes and will take some time leaving the possibility of scene interactions more likely.
curiousB
I have experienced that if you are using IOS or Android to create a scene because the web app will not show all of the useful parameters of a device and save that scene, then go into web app and try to edit that same scene it will not show on screen , the screen will be blank.
I am still having issues with scenes not actually turning ON a light or appliance , and also if the web app sit unused for sometime it will not work at all until you refresh the page. Also they have not yet allowed you to include or exclude anything from web app , still only from Vera app can you do this.
I am still waiting on my RMA either they have so many going back or their is only 1 person for that whole dept.
My suggestion wait for more of these issues to be corrected before changing over if you can.
Hello @curiousB
Could you give us more details on the issue you faced? We need to know details of the meshbot you created and a description of the steps you made, and the final result - what issue did you see?
It will be helpful if you provide us logs after this scenario execution in order for us to investigate this behavior of the meshbots.
Please, let me know if you need assistance from our Customer support team.
Its pretty simple. I have a hub with seven ZWave light switches and/or dimmers. Very small Wave network. Some plug in some in wall.
I have one scene that turns all seven lights on immediately and another scene that turns the same all off immediately. This is by listing each device as an item in the action portion of the scene.
I then have another pair of scenes to turn them all on and another to turn them all off but rather than listing each item in the action section I have LUA script that sequentially turns them on or off.
The problems I get occurs whether it is the listed device action script or the LUA code script. They both fail the same way.
If i start the turn on scene but as soon as the green check mark ends on the scene page in my iPhone and launch the all off scene that is when problems occur. If I wait a few seconds after the scene completes to launch the second scene everything seems to be fine.
My suspicion is that the first scene isn’t completed when the second scene starts out and that the ZWave handshaking for the various devices gets confused. Scene “all on” is waiting for a node ACK while Scene “all off” is sending a new command to the node. Somehow I think the ZWave commands are getting interleaved across the two scenes running. This is just my guess.
Anyway ZWave actions need to be rock solid. They can’t be attempts to change state as they seem to be today. The retry mechanism should try a few times to get the confirmed state set and if it doesn’t happen there should be some error flag. Vera would tell you if the ZWave command didn’t work. Not sure why Ezlo buries this.
Lastly the state showing in the iPhone app can be out of sync with the devices actual state when this happens. The light may be actually on but the iPhone indicator is that it is off. This adds yet even more confusion.
So there is a lack of integrity with the execution of state changes and Ezlo knowing what the state actually is at the node. Vera didn’t have these issues.
I had one ZWave device that seemed to be marginal for signal. That node eventually died and became uncontrollable with an error something like “device failed to communicate”. I tried the rediscover device under ZWave for that device but it didn’t work. So I deleted the device, unwired it from the wall, powered it up with temporary power next to Ezlo box and added it again. Then I reinstalled it in the wall location. Since then it seem to be much more reliable.
I should add the device was originally enrolled or added to Ezlo from far away, 60-80 feet away and a couple walls. I wonder if marginal signal led to a botched enrollment registration (with insufficient error checking) that compounded matters. As I have mentioned before probably needs some testing from Ezlo on weak nodes not just pristine nodes next to the box. I think my scene issues were due to extended handshaking of the ZWave nodes which is more likely to occur with fringe nodes. Thinking this might be an important clue to some of the instability issues as compared to Vera.
Another update here. Since I deleted-reinstalled the rogue device in close proximity to Ezlo the device has been rock solid. Not sure if this repairing did the trick. I did happen to add another ZWave device near to this far away one so perhaps that has provided an alternative hop path back to Ezlo. Eitherway my erratic Zwave behavior has all but disappeared.
I have found that the controller MUST be next to the device in order to create a solid connection. So much for the Z-Wave promise of being able to include even when hopping through a few nodes to get there…
At any rate, I have a battery pack for a phone that I just plug into the Ezlo and walk around the house to each device and include it up close and personal. Just be sure to make sure your Ezlo’s WiFi is on and correctly configured.
There are a lot of promises that Z-Wave makes (especially about the latest 7 chips) that Ezlo just can’t seem to turn into reality. Most notably - we were promised by the Z-Wave guys way back when Z-Wave first came out (early to mid 2000’s) that the protocol has built-in checking technology so the days of asking a light to turn on and it never does are over… Ezlo has proven that that technology doesn’t work the way’ve they’ve implemented.
I am not sure what is going on but I think there is a big difference in how ZWave is handled in Vera Products vs Ezlo. My guess is Ezlo is a much more hands off approach to the ZWave stack with Ezlo using an API from the ZWave chipset vendor to implement the low level communications. The problem with this is there are race conditions and unintended consequences of the timing of the protocol ACKs/retries/hopping, … at the lower levels and how they dovetail with the status reporting at higher levels in the Ezlo app. Bottom line its difficult to layer these perfectly such that they are truly independent. It really requires a system approach to ensure all the error legs needed to handle the many degenerative cases that emerge. I suspect these error legs are missing with Ezlo today. Often with this type of S/W development, 25% of the effort is to get the nominal case working, and another 75% to get all the degenerative scenarios handled. Overtime (years) Vera got the error legs added, I don’t think Ezlo has and is treating ZWave as a black box interface/API. So I am not sure it will ever achieve the kind of robustness we enjoy with Vera. That is a shame given the promise of the newer ZWave chipsets and protocol enhancements seem largely unrealized.
We will have a deeper look for the specified case of “running one meshbot with zwave devices before the other one which has the same devices, completes”.
Meanwhile it may be useful if we can get some logs from your hub while performing this scenario. @SaraV can you assist on creating a ticket and getting the logs please.
My system is not running at the venue where I had the problems a few months back. It is a seasonal home.
Regardless I think you could test it in one of your labs. Just populate a controller with a few to several ZWave devices. Ensure at least of a couple of them are far away and at the edge of marginal RF coverage. Then see what happens when you create scenes to toggle them all off and all on (not using global all off or all on commands) but by sending each device individual on or off commands.
My belief is the ZWave stack gets confused when a large number of concurrent ZWave commands are in process and some of them get into retry efforts due to weak coverage and/or interference. I don’t think the system is hardened enough to overcome these rogue conditions. Things like exponential back off, keep retrying until confirmation, perhaps some conflict between low level retries (ACK/NAK) and some upper level retries (creating a race condition?), or send a error message the device couldn’t be contacted after x tries. Vera used to show a red dot in the GUI if all the retries failed.