I havent tried that for a while but I wrote about it before previously here
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.
Which part exactly did you get stuck on and what errors were you getting and where did you see those errors ?
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 ?
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.
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.
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!
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.
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.
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.
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.
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!
Thanks for your comment! I agree with every single word you wrote. Every one.
I submitted a feature request for this. FYI the ticket number is ECFI-1 !
Is this an internal ticket system? The others always start with ECS-…
Its internal unfortunately. I also added your other suggestions regarding System Meshbots.
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)
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
Hello @jouked
Thank you for your feedback.
We have re-opened the threads that were closed and will continue with the process.
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:
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.
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.
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
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules