Wish list for Ezlo

[jouked]

@melih

Users providing feedback…(needs to be clearly defined)
Ezlo receiving the feedback and creating a unique ticket for it
Ezlo executing the ticket
Responding to users with status…
If we kept doing it, we’d be running the Deming cycle which will result in continous improvement.

I understand that after the last step (respond with status), the user feedback should start again. However, I think there is a practical disconnect there.

A couple of examples from my side:

Nucal / Netatmo integration has not been working (I think ever). See thread Updates for EZLogic - 1.44.1 (Ezlo Hubs only) - #8 by osman. Osman responded on the issue more than a year ago. The situation has not changed, integration is still not possible to setup. Hoever, it ends without proper response to the user.

FGD-212 integration, 1. ECS-1165. The issue is one year old without updated. I’ve ran into actual issues with the integration, where I had unwanted meshbots run on a daily basis, for about 2 months recently. That issue is gone, however the requested scene control functionality is still missing. Again, it ends without proper response to the user with the status.

InstaVue not being instant, see https://community.ezlo.com/t/instavue-far-from-instant/220968/2. Again, ezlo responds with working on this, but there has been no update for about 5 months on this. Meanwhile, the doorbel camera is just useless, no way I can get any live video before anyone at the door has already walked away. Again, there has been no feedback with a status update and it’s still broken.

Vistacam stopped recording, see https://community.ezlo.com/t/beta-vistacam-stopped-recording/220326. I reported this over a year ago, there has been no feedback with a status update and it’s still broken.

Within your support processes, there must be something missing to conclude these issues. It would help to get some response, something like:

• ‘We are aware, but we won’t fix this’
• ‘We’re working on it and we’ll update the status bi-weekly’
• ‘We think it’s fixed, can you check the result and provide feedback before we close the issue?’

I’m not really complaining here, I’ve been an Ezlo hub and Vistacam 1203 beta user, got the devices for free as part of that deal, so I’m in it to learn, provide feedback and hopefully end up with a powerful solution.

[melih]

@jouked

However, I think there is a practical disconnect there.

I don’t think we have the process running yet.
So you are right, we have a disconnect.
We are having an internal meeting next week to setup this process.

[cw-kid]

I agree with some of the sentiments on this thread and some of your frustrations.

Personally 95% of my Z-Wave devices are still paried to my rock solid Vera Plus hub if I have to reboot that thing 2 or 3 times a year thats it. It keeps on going and working…

We never used the native Vera app, as lets face it, it was always terrible, the new Mios app built on top of that, which I always felt was a mistake and we should have had a new mobile app built from the ground up.

Why we always used the various and much better 3rd party dashboard apps. I used a few of them over the years, currently I’m still using my customised Home Remote app.

And for logic engine im using MSR.

Meshbots is getting closer but its not quite there yet.

I have been patiently waiting for the entire Ezlo platform to mature until I consider unpairng and pairing all my devices.

Ezlo are doing some nice extra fun projects like EzloPi but think they need to pull back on those and put all their developement time in to the core system to make it more stable yet. Z-Wave / Zigbee / plugins / Meshbot rules / Ezlogic web UI / Mios app / Stand alone local Dashboard app / Voice Assistant integration etc etc.

Ezlo system has a lot of promise, but I think they need to get back on track with these core areas first.

I’m still happy with my Vera firmware hub for now.

My 2 cents.

[JonathanB]

Hello,

Thank you for taking the time to share your comprehensive feedback regarding your experience with our platform. We truly appreciate your insights as they are invaluable in guiding us towards improvement. Rest assured, we are committed to addressing the issues you’ve raised and working diligently to enhance your experience with our platform. We have listened to you!

Here’s a summary of the key points you’ve highlighted along with our plan of action:

• Professionalism and Communication: We acknowledge the need for better communication and transparency. We are taking steps to improve our communication channels, update schedules, and documentation. We aim to provide clear and consistent information to our users to ensure a more professional experience.
• Documentation: We are aware of the discrepancies in our documentation and are actively working to rectify them.
• Community Engagement: We understand the importance of a vibrant community and will take a leadership role in fostering its growth. We will actively engage with our community, provide support, share strategies, and encourage collaboration among users to drive positive change.
• Specific Capabilities: We are committed to addressing the limitations in specific capabilities such as cloud services and MeshBot functionality. Our development team is working on resolving these issues and will provide updates on their progress.
• Apps and User Interface: We are working on improving our apps and providing better guidance on recommended activities across different interfaces. Additionally, we will explore options for integrating voice assistants to enhance user experience.
• Issue Tracking and Feedback Collection: We want to ensure that every concern raised by our users is properly documented and addressed. As you mentioned, we utilize Jira for receiving requests and issue reports. You can access our Jira Service Desk at Service Desk. Additionally, we will continue to monitor the community forum and support tickets closely. By collecting feedback from multiple channels, we can ensure that all issues and suggestions are thoroughly reviewed and addressed by our development team.
• Real-World Testing Environment: To enhance the reliability and stability of our platform, we recognize the importance of testing in real-world scenarios. Therefore, we are initiating a special project to conduct testing in environments outside the laboratory. This will allow us to simulate real-life usage scenarios and identify any potential issues or improvements needed to provide a seamless experience for our users.

We are committed to implementing these measures to address the concerns you’ve raised and to ensure that Ezlo continues to evolve as a reliable and user-friendly home automation solution. Your feedback is invaluable, and we thank you for your continued support and collaboration.

[ram]

Really glad to see the positive response and energy on this thread. Feels like all involved want to drive positive change! Ezlo team, as you do your process work, I would suggest keeping two recommendations in mind -
First, establish and publish target dates for every issue, improvement and suggestion to be implemented. If you are going to work on it, tell us your target date for getting it done. As others have noted, if you aren’t going to work on it, clearly tell us that as well. If dates need to slip, that’s ok, just tell us the new target. I, for one, can deal with the fact that not everything can be a top priority, that some things have to be put on a back burner and that sometimes, despite best intentions, things don’t get done on time - just communicate!
And secondly, celebrate your successes! I believe you are getting a lot done but if we can’t see the progress you won’t get much credit for it here or in the industry. Don’t be afraid to list your accomplishments regularly, maybe even in conjunction with your list of next areas of focus.

[cw-kid]

@ram

Right now there doesn’t seem to any working method to fetch local weather data - Open Weather and Ezlo weather apps both return errors

I havent tried that for a while but I wrote about it before previously here

How To - Nucal OpenWeather data as a Meshbot trigger example

UPDATE - “Cloud Variables” are currently String variable type only. So some logic operators may not work as you might think or give you unexpected results. Probably better to follow this newer guide here, where we use “Local Variables” and an integer variable instead. ‐-------------- I decided to look in to this as another user asked the question on the forum and I wanted to see if it was possible. He wanted Cloud cover data from OpenWeather service and use that as a trigger in a Meshbot ru…

And an updated way here, where I was pulling down weather data from the “Nucal” now named “Cloud Services” Open Weather service and I then used a LUA script to extract the particular piece of weather data I was interested in from the local Variable etc.

How to - LUA Script to extract particular data / value from string variable (JSON API) HTTP Requests

I am using OpenWeather in this example however this LUA Script should work for any JSON data you have managed to download via a HTTP Request, from an online API server etc. Currently in Ezlogic you cannot use a relatively simple one line “Expression Code” to extract a particular piece of data from a variable. For example say you have a Meshbot rule to send a HTTP Request to the OpenWeather service and you store that downloaded weather data into a local string variable. It may look something li…

Which part exactly did you get stuck on and what errors were you getting and where did you see those errors ?

[cw-kid]

@ram

I use the Deus Ex Machina II app on my Vera devices to provide a lived in look by randomly turning lights on and off in the evening. As far as I can tell there isn’t a substitute for this that works on the Ezlo platform. This is a critical need for me. Perhaps someone in the community can write a similar app for Ezlo, I know I can’t.

I never used that Vera 3rd party plugin, but house occupancy simulation whilst away sounds like a good idea. Perhaps we should put a list together of the features and functions that old plugin covered and we could maybe submit a new feature request to the Ezlo team for a similar new plugin or inbuilt functionality, what do you think ?

[ram]

Originally I was pulling local weather data from the Ezlo weather app but that stopped working some time ago. I saw that issue pop up on this site and so I wrote a Meshbot to pull my data from Open Weather instead using Cloud Services. That worked perfectly for a time but sometime this winter it stopped pulling in data. When I investigated, I found that I could no longer access Open Weather using the Cloud Services function - when I tested the pull process in the Meshbot it would return a 400 error, same as what the Exlo weather app would do. I put a ticket in and was told this too was a known issue that will be resolved with the next update but no date for that was provided. I do have a weather station and have thought about using your guide for HTTP requests to pull directly from that but I haven’t invested the time in that yet to see if it would work. Appreciate the response as it really seems as if I might be missing something with this. I would have thought that many folks would be pulling and using local weather data.

[cw-kid]

Well there are several ways to go about it as you say. I think in those example posts I made I was talking about using the Nucal / Cloud Services features for either Ezlo or Open Weather.

And in the Meshbot pulling down the data from that cloud service and storing it in a variable.

Id have to read again what I wrote to refresh myself. I might try it again this week, see if I get the same 400 error as you now?

The other way would be to not use the Nucal / Cloud Services part and just do a straight HTTP request in your Meshbot rules action to say Open Weather and then store the weather data in a variable and extract via lua script which bits of data you need.

And as you say you could even do a http request to your own local on site weather station if it has a local Http API you can talk too.

[ram]

i found the Deus Ex Machina II app to be really well executed and easy to configure for my needs. In essence it allows you to:
Select the time frame you want activity to occur - i.e. in my case from 6 pm to 10 pm
Select the devices you want the app to utilize during that time period
Select the max number of devices you want on at any one time
Select the minimum duration for any station or device to be on,
The app then turns on devices at random to simulate normal activity.

It’s been a while since I configured this so there may be other functionality I don’t recall.

I have not studied the actual performance to see how random it really is but I know the start order is not always the same and for me it is random enough to not just look like a timer turning a lamp on and off.

Enhancements I would like to see would include the ability to use sunset with an offset for start time and the ability to set a range for the end time so it can vary the “lights off” time.

Several of my Vera’s are at vacation type properties and so I appreciate the ability to simulate the lived in look when in Away mode. Would be great to have an app or functionality like this on the Ezlo platform!

[cw-kid]

I haven’t tried the “Cloud Services” / Nucal for Ezlo or Open Weather again yet, however a product manager told me the following.

“NuCAL has re written all their services…hence not functional…
Ezlo cloud team is rewriting all the services again, once they complete it, it will be functional”

I am not sure why they had to break existing working functionality to re-write it again? But who I am to ask. So that probably explains your 400 errors.

So I would say avoid using “Cloud Services” for now in Ezlogic web UI.

Instead just use the HTTP Request node in a Meshbot rules action and send a straight HTTP API command to something like OpenWeather, store all the returned weather data in a string variable, create a LUA script to extract the exact peice of weather data you are interested in, to a second variable (integer variable in my example) and then use that variable in your other Meshbot rules trigger or whatever.

That should still work and can be used as another way to do it without using the “Cloud services” / Nucal stuff.

How to - LUA Script to extract particular data / value from string variable (JSON API) HTTP Requests

I am using OpenWeather in this example however this LUA Script should work for any JSON data you have managed to download via a HTTP Request, from an online API server etc. Currently in Ezlogic you cannot use a relatively simple one line “Expression Code” to extract a particular piece of data from a variable. For example say you have a Meshbot rule to send a HTTP Request to the OpenWeather service and you store that downloaded weather data into a local string variable. It may look something li…

[cw-kid]

Yeah the other way to do this using Nucal Cloud Services method is definitely broken, I just looked at my rule and I get the same error 400.

[cw-kid]

@ram

Open Weather and Ezlo weather apps both return errors. And even if I could get weather data, local meshbots don’t currently support simple math comparisons to support the logic i want to implement (simple stuff) and while global meshbots do the math, there is some sort of undefined error according to support that causes them not to function correctly. Said to be rectified in the next update but no word as to when that will drop.

Can you give more detail on the math comparisons you wanted to do but were unable to do in a local meshbot ?

And maybe show that vs a cloud meshbot?

I know if you followed my original guide here, I was using a “Cloud” variable to store the bit of weather data I was interested in.

However I later found out that Cloud Variables are only of string type.

So me storing a number in a string variable and then trying to do a Meshbot rule trigger like temp > than X number didnt work properly.

The Cloud variable for that to work and do the math properly would of needed to be an integer variable instead.

So that was a limitation I found. I created a ticket to see if other types of variables other than string could be used for a “Cloud” variables, but I never heard anything about it I dont think.

I then moved on to doing it the other way here and not using the Nucal Cloud service way and just using a HTTP command, two variables one string one integer and that lua script. More difficult to setup, but it worked better as I then was using the integer variable in my rules trigger etc.

[cw-kid]

Also they seem to have some functionality missing. When using the Nucal Cloud Services method in your Meshbot rule when you select Output to Cloud variable, you get this nice drag and drop part, where you can just select the particular bit of data you are interested in.

clouds_all in this screen shot.

However if instead you select output to local variable, you lose the nice Data Structure and drag and drop stuff and all you can do is select an existing local variable from the drop down menu.

So you then lose the ability to extract / pull out just the one piece of weather data you were interested in.

Thus why I went down that rabbit hole in the other thread of having to use a LUA script to extract the data to a local integer variable instead.

They really need to have that data structure / drag and drop ability for both cloud variables and local variables.

I created a ticket for this also but looks like they havent done it as yet.

[ram]

I now see that my issue with the local meshbot was exactly what you note - I was using a global variable and getting the error about only supporting strings.
I used the global variable for the reason you noted in a later post - the global variables had a nice drop down menu to choose what I wanted and I wasn’t sure how to do that with a local variable without more work and research.
Global variables of the right form apparently do evaluate as integers in global meshbots however so I went that route. No problem writing the simple meshbot with > than or < than comparisons to turn a virtual switch on or off but it did not evaluate properly - when temp was clearly over the target the switch would not change state. Support opened a ticket for this and did a behind the scenes fix to one meshbot for me. After the fix it did evaluate properly but they didn’t / wouldn’t share what they had to do to make it work so I could adjust my other, similar meshbots. This was the issue they stated would be resolved with the next firmware update.
So if I can get the weather info into a local variable following your http guide I should be able to make all this work. I won’t be local to the controller for another week though so the rest will have to wait.
Really appreciate your how to guides and explanatory posts on other topics!

[FxEpic]

Thanks for your comment! I agree with every single word you wrote. Every one.

[cw-kid]

@ram

I use the Deus Ex Machina II app on my Vera devices to provide a lived in look by randomly turning lights on and off in the evening. As far as I can tell there isn’t a substitute for this that works on the Ezlo platform

I submitted a feature request for this. FYI the ticket number is ECFI-1 !

[Odysee]

Is this an internal ticket system? The others always start with ECS-…

[cw-kid]

Its internal unfortunately. I also added your other suggestions regarding System Meshbots.

[jouked]

@melih

I don’t think we have the process running yet.
So you are right, we have a disconnect.
We are having an internal meeting next week to setup this process

I think the first results are visible on the forum, several threads with ‘loose ends’ being followed up and solutions being shared where possible. Great!

As a suggestion, I would not close the actual thread once the issue has been resolved. It’s quite normal to continue the thread if another person has more suggestions and / or similar issues. A thread is not a ticket that must be closed, it can be an ongoing discussion. (see Kwikset Lock and Ezlo Plus (Series 700 chip) - #7 by JackStewart)