Zipato, please make virtual modules local

Well, I had a look in the API (after reading another similar topic) and found that a virtual endpoint calls the zipato servers:

[

{

"link": "https://my.zipato.com/zipato-web/v2/virtualEndpoints/UID_1",

"name": "Aanwezig",

"room": 55256,

"uuid": "UID_1"

},

{

"link": "https://my.zipato.com/zipato-web/v2/virtualEndpoints/UID_2",

"name": "Alarm CO2",

"room": 55256,

"uuid": "UID_2"

},

...

When the connection to the cloud failed and I looked at the virtual switch values in the WEB console they all had a value either true or false. But when I looked at those values in the android app, after refreshing it, I noticed that the virtual switch values had NO value, it showed "-". Some virtual switch values got a value when a rule was triggered that set that value. Other I had to set manually. After that all my rules worked OK again.

I think that the virtual modules should store their values locally to get a more reliable system.

Interesting idea, can you provide me with a example rule?

Obviously it depends where the information comes from. For example, if you detect a one-time event and store information about it, you're screwed (an example is setting a "daytime" switch at sunset and sunrise).

But there are sometimes ways to refresh information periodically. In the case of sunrise and sunset, I use a Google App Script to feed the sunrise and sunset times to the Zipabox every few minutes, and then calculate from there how long it is since sunrise/until sunset, etc. And obviously refresh the daytime state. I give the details here:

https://community.zipato.com/topic/need-a-way-to-store-and-compare-datestimes#comment-26273

I do the same for weather information (I find that the Zipabox weather information is updated very infrequently, sometimes not for hours). The Google App Script in the above link also includes the code for getting weather information from Wunderground and OpenWeatherMap (Wunderground is by far the most reliable).

Most of the other values that I have in the Zipabox are calculated from basic information that is available right from boot up, or from these external sources. For example, is today a weekday? Is today a public holiday? Is the weather overcast? Is there sun on the south side of the house? Should the awnings and blinds be lowered to block it (warm season) or raised to let it in (cold season)? And so on.

The basic pieces of the system are:

1. A master scheduler rule that runs every minute, and which triggers everything else. I find this much more reliable than using scheduler pieces in each rule (I haven't tested schedulers recently, so perhaps they now all work reliably - but it didn't used to be the case). In any case I likely having all the rules that run periodically in one place.

It just updates the sunset/sunrise variables (see previous link), then works out which rules to run this time (the ones that run every 10min, 15min...), and calls another rule that does everything else.

You could simplify this by running each "recalculate" rule every 10 minutes, setting a rule to run every 10 minutes, and triggering everything from that.

To trigger other rules I use virtual switches. The rule runs on any change to the switch state, and the calling rule toggles the switch.

2. A "run scheduled tasks" rule run from the master scheduler. First it detects whether there has been a reboot - this takes advantage of the fact that variables values are reset on reboot. Search for "reboot detector" on this forum. If so, it immediately runs all the rules to recalculate everything. I use a guard variable in my other rules to prevent real-world stuff happening (like blinds or awnings moving) whilst this recalculation is happening. It also has a special "alarm" function which is not important here. If it's not a reboot, then it runs 10-minute rules on multiples of 10 minutes, 15 minute rules on multiples of 15, etc. etc.

With luck, the values of external sensors and meters will be restored when the Zipabox reconnects to the cloud.

I'll post a couple of screenshots.

Here's a piece of the Run Scheduled Tasks rule and the complete Daytime/Sunrise/Sunset rule (the link I shared above only shows part of it).

Let me know if you want examples of anything specific.

Another way to correct the daytime state would be with a light sensor.

Even with a temperature sensor you could perhaps make an educated guess providing you know the maximum/minimum temperature (sadly in the Zipabox weather device they always appear to be zero).