Wish list for Ezlo

Ezlo Edge Computers General Discussions
#16

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.

#17

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.

Screenshot_20240312_032659_Chrome~2
Screenshot_20240312_032659_Chrome~2720×1332 115 KB

#18

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.

#19

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.

Screenshot_20240312_035546_Photos
Screenshot_20240312_035546_Photos720×832 131 KB

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.

Screenshot_20240312_040333_Chrome
Screenshot_20240312_040333_Chrome720×477 44.3 KB

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.

#20

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!

#21

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

#22

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

#23

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

#24

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

#25

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)

2 Likes
#26

Agreed threads should not be locked unless there is some good reason to do so like an argument or something along those lines.

I re opened the referenced thread

2 Likes
#27

Hello @jouked

Thank you for your feedback.

We have re-opened the threads that were closed and will continue with the process.

2 Likes
#28

Was there any progress/result from the meeting?

There were/are lots of suggestions for improvements from users. Whether here in the forum or in the Community Feature Request and Bug Tracker. If more attention was paid to this, it would take the platform a big step forward. The things with EzloPi, EzVidoo, etc. are great ideas, but it seems as if there are hardly any resources left to deal with the ideas/requests of the users. And that’s what matters.

There are so many basics that are simply not what you would expect from a smart home system. Just a few examples:

  • Dashboard: Many users want to create/design the dashboard themselves. At the very beginning it worked, although in my opinion it was virtually unusable. Then at some point it was blocked and there was an alternative dashboard designer to choose from - but also without function. It was promised that it would be completely rebuilt. And then came… nothing
  • Data Logger: If you look at the competition, you can see beautiful graphics, measured values and curves of power consumption, brightness and temperature over time. It doesn’t exist here and is somehow hushed up. I don’t know how many times I asked about it. But there was never a single comment like: Good idea, it’s planned or we don’t have plans because. It’s a shame, because in my opinion it’s exactly things like this that make an impression on users who want to evaluate data or simply because it looks cool. For example, I’m currently trying to record the power consumption of my devices. Instead of simply using Z-Wave sockets, I’m buying WLAN sockets again because they have a data logger function.
  • Plugins: Formerly one of Vera’s flagship features. You could find almost everything there to integrate your non-Z-Wave devices or other functions. Now there are only a handful of them, and you don’t even really know how to get them to work (at least that’s how it works for me. It’s still possible to install, but you’re left with no instructions or anything like that when setting it up).
  • The app and web frontend are still not on the same level. For example, why can I only include devices with the app and why can’t I restart the controller via the web frontend (I can only do that via a function in a MeshBot). And why can you shoot each other’s MeshBots or scenes?

Those are enough examples that come to mind straight away (and enough text too). I would like to see more focus on these basics instead of always inventing new things. I think these are great too, but I think in order to attract new users and, above all, keep them, these basics need to be prioritized much higher.

#29

Hello @Odysee,

Thank you for sharing your concerns and suggestions with us. We truly appreciate your feedback and want you to know that we are actively working to address the issues and suggestions raised by our users, including those from the forum and the Community Feature Request and Bug Tracker.

Rest assured, your input has been noted, and we are committed to prioritizing the improvement of our platform’s fundamentals. We understand the importance of features like dashboard customization, enhanced data logging capabilities, and plugin functionality. Our team is dedicated to making significant strides in these areas to ensure a more seamless and satisfying user experience.

Your comments have been added to our tracking list, and we will keep you updated on our progress. Thank you again for your valuable input, and please don’t hesitate to reach out if you have any further suggestions or concerns.

#30

You can do this today but I’ll agree it is so buried in the tree its not intuitive to find.

 >>> Settings/controller/function/maintenance-remove/reboot
1 Like
#31

you can create meshbots with “reboot” capability…so that you can simply click to run them if you want to make it easier.

#32

My gut reactions to all of the above . . .

Fix the Docs
Speaking as the author of much (most?) of the original Vera documentation, and a die-hard MiCasaVerde customer since its inception, heartfelt posts like the OP both gratify and astound me. We’ve had 15 years now to get the documentation in order, and while it is a moving target, there’s no (good) reason that each and every product feature, driver and app should not be fully accounted for at this stage.

Fix the Forum
Without dwelling on “how much better things were before the takeover”, it’s important to at least acknowledge that the Forum has grown quiet over the past few years for one very specific reason: Our most active, loyal and knowledgeable members – including dozens of our best and brightest developers – were summarily banned in a fit of pique. AITA for mentioning it?

Side Note: To help underscore the brain drain phenomenon . . . I’ve been gone for years, yet out of 57,000+ registered Forum users, I am somehow still in the Top 30 of All Time Contributors . . . WTH??

Be More Professional
I saw your “Vera / Mios / Ezlo” reference and enjoyed a good belly laugh. Like many here, I have a giant drawer full of Vera / MiOS / EzLo controllers that have either reached EOL or no longer require beta testing. The lackluster brand promotion and market penetration over the past few years leaves me without a ready path to repurpose those items, since nobody in my (fairly vast) circle of tech buddies has ever heard of, nor wants, them. I had higher hopes at one point, but don’t see any momentum in this area. Instead, the most recent messaging concerns X10 support (sorry, that ship has sailed) and RasPi project boards (sounds like a pet project for someone with kids learning about home automation?).

Issue Tracking
This is such a sore point, for me, mostly because I got to see firsthand what a stellar job devs like @rigpapa did with beta testing his juggernaut app MSR, using JIRA ticketing along with an outward-facing UI so all users could not only review active issues, but contribute (this is the magic sauce) input toward resolution. Why ezlo staff go the opposite route of taking issues offline or handling them exclusively internally is a mystery, leading me to suspect their aim is merely to keep the Forum (looking) clean. Egos aside, there’s never an excuse for quashing customer feedback, good or bad.

Third-Party Integrations
This was once Vera’s strong suit, yet (whether due to schizoid messaging or failure to market) it’s unclear to me whether add-ons are even a current component of the MioS-sphere. To the extent plug-ins like PLEG and later Reactor saved Vera’s bacon by adding the kind of functionality which modern customers demand and rightly expect, they simultaneously highlighted ezlo’s early weaknesses which seems to have led to a never-ending game of catch-up. It’s no secret that Multi-System Reactor indeed became, for many users, a welcome “ticket out” by allowing all hub logic to be offloaded into an instance of MSR, ultimately to be ported over to another more robust (nameless, for reasons) platform.

Community Engagement
I respect that paid staff cling to the assertion that this is somehow still on the table, but it’s been made abundantly clear with every stated deflection and minimization by ownership that the ezlo ecosystem remains the brainchild of one person, the guy who pays the bills, and thus whose sole vision drives the company mission. Had this indeed been a team effort from the outset, the Forum would be filled with the kind of Customer Feedback @ram seeks. Instead, the discussion leans heavily toward “Wait a little longer” and “We’re (still) working on it” and “We heard you” and “We thank you for your continued support.”

We-You. We-You. It stopped being “Us, Together” a long, long time ago, IMHO.

#33

Is there a comprehensive list of all the features and functionalities that are in development and bug fixes and where they stand?
Cloud services that don’t work are still available to add but fail.
Google/Nest integration still seems incomplete and has bugs.(they are listed throughout the forum so Ezlo staff can comb through them to test and report)
I see a lot of we plan on that or we’re working on that. It would be nice to see the roadmap for features and releases for planned bug fixes. I would think there has to be some sort of document that details this.

1 Like
#34

I would say the Community Feature and Bug Tracker comes very close. The only thing missing is the schedule of when something will be processed/implemented. Unfortunately, I have the feeling that very little is happening here. Every now and then one of the staff seems to grab a few cases and answer them. Then there is peace again for a long time.

1 Like
#35

I was told that they were looking at all outstanding tickets on the community tracker for “Feature Requests” that we have made to them and they will be prioritising those outstanding requests and hopefully they will then get some development time. I know I made quite a lot of feature requests, some were added and are now in the system today, but some have not been as yet.

1 Like