Test of virtual switch state failing

I think I may have a clue about what's happening. The "working day" switch appeared to be set to "on" in the device manager. But I read in the forums that virtual switch states are NOT preserved after a reboot (in contrast to what I believed). So I tried toggling the switch off and then on again. Then I ran the rule. Bingo, now it worked in all 6 cases.

So there is still a bug: sometimes the Device Manager shows a state that is not correct.

I'll change the logic of my rules to regularly refresh the switch states (or use variables maybe).

Could it be that if the box disconnects during the night, it loses the switch states, and then fails to reestablish them on reconnecting? So you continue to see the original correct switch states in the web application (because they're correct in the cloud) but on the box the states have actually been reset to "off"?

I've just done a test which proves that, when a switch is not behaving as it should, its state is out of synch.

My "working day" switch appeared to be on in the Device Manager. But the conditions which tested for the "on" state evaluated to false. So I tried running a rule which toggled the "working day" switch twice. Toggling the switch twice will not change its state, but will force a resynch of its state between the box and the cloud. Since the rule is executing on the box, the starting state will be the box's state, not the one you see in Device Manager.

As expected, after toggling the switch twice, it changed from "on" to "off" in Device Manager.

So Device Manager is lying about the state. It's not synched to the box (or, rather, the box has not been resynched to the cloud state after a disconnection).

Zipato: you need to fix this. This is almost certainly the cause of a lot of the unreliability people are reporting in the execution of their rules.

Also, it would be useful to be able to trigger rules on certain events, such as a reboot or reconnection to the cloud.

Hi Dave, all respect to you writing a long book to find our a bug in the system. I will definitely save rhis for future reference. I appreciate that great guys are part of this forum like you...

Hi, David,

You are correct. The problem was with the box receiving last states from the cloud. After the box reboots the cloud immediately sends the switch states to it. The problem was that sometimes the connection to the cloud was not fully initialized, and the states from the cloud never came to the box. That is why they appeared off, and why they showed different values in the device manager. We have fixed this issue by waiting for a few seconds for connection to start working properly after the box reboots, and then send the state from the cloud.

The problem should be fixed if you update to beta.

We appreciate Your valued input as a customer, and we apologise for inconveniences this issue caused.

Kindest regards,

Sergej Hajdin

Zipato Team

Excellent, I might risk it and try the beta firmware. Is it easy to revert to the earlier firmware if I have problems?

Do you have a list of problems fixed in the new firmware?

Dave,

I'm aware of a few issues still present in the latest firmware;

1. Groups of sensors don't work at all, and if you tie any virtual device to a rule which depends on a group then the virtual device won't work either.

2. Repeat puzzle don't work at all if you put a Join puzzle inside it. Also, if no Join puzzle is present, it won't work the first time you execute the rule, after that it's fine.

3. I think they still have problems with the insertion of variables in the messages (I don't know because I don't have the PRO licence, and 99 bucks for that sounds a bit expensive, maybe I will buy it when I need other PRO feature).

OK, thanks for the info. I have some groups but I'm not using them at the moment. I don't have any rules that use Join. And as for messages, I just tried an email which gives me the states of switches and variables, and it seems to me like the ones that are not synched don't make it into the email properly (in this case, Working Day., Weekday and On holiday:

Variables:

WorkingDay: ${variables.get("WorkingDay")}

Switches:

Weekday: ${attributes.get("27bc9d7f-f126-470b-b8c5-b5e4f82a9245", "com.zipato.cluster.OnOff", "state")}

Working day: true

On holiday: ${attributes.get("e47b2f74-501c-4b01-b7b0-19826ee22d2b", "com.zipato.cluster.OnOff", "state")}

Autumn/winter: false

Spring/Summer: true

The rest work.

Did you tried if you can add variables or states to push notifications?

No, I've never tried push notifications. I'll maybe give it a go.

To understand what happens in the Zipabox you must create a rule that sends a message every time the box restarts spontaneously. It happens more often than you can imagine. And every time the hole memory are cleared. What you se in the device browser has very little to do with what the box remember of the status from before the restart.

Just create a simple rule as this and you get a message every time the box restarts.

How do you configure the scheduler?

David.

This was nearly a novel. :) :) Please wright on this level. It will be easier to discuss a single point then. Thanks for your trust.

I'm quite restrictive with what I writes. I will be sure it's correct. The lack of both documentations and debug systems makes it extremely difficult to be sure.

I became a developer myself many years ago (systems for sawmills) and then development director and CEO for about 100 developers. Now I'm retired.

I think that Zipatos concept is a great idea. That's the reason why I still waits fore the next release. I don't want to disturb them with hard and wrong words in public. I only hope that they recognize, by them self, that they have created a system which are too dependent on too many stage that all have to operate at the same time when the system should run. The same problems that you have in an industri. A line without buffers between machines results in a very low efficiency. If each machine have an efficiency of 95 % a line with 10 machines will be down in 49 % efficiency. Upon that we have all the risks with the cloud. In many systems it doesn't matter if the system is down fore a while. My living in a house, in a cold country, must works every minute. I still hopes for a lokal interface and understands the cloud as a superb way to admin the system from other places when it's possible.

David.

You wrote: "However I already have a suspicion - more than a suspicion, actually - that there's a big difference between variables and switches."

There are a big difference between variables and switches.

A variable stores numbers and a switch stores true/false.

if you don't want to use variables use virtual meter. Those stores the same.

Henry,

Oops I nearly didn't see your last message.

Yes, we need more documentation, definitely. At the moment this forum is almost the only place to get information.

From my review of the home automation options out there, I have concluded that this is still a hobby for tinkerers rather than something stable that can be sold to the public at large. All the good systems seem to have reliability problems, except the installer-only ones which cost a fortune and are just mostly useless toys for people with too much money (that's my impression!). So for the moment I've decided the best bet is to stick with Zipato and try to improve the system as far as we can. The more people post constructive criticism and tips, the better.

For my part, I don't depend quite as much on the system as you do. In part that's because I can't (yet) control my heating from the Zipabox. Mainly I depend on it for awning and blind control (to let the sun in in the winter and keep it out in the summer - I live in Spain - as well as getting some extra insulation on cold nights), corrections to the ventilation control (turning it off if CO2 is low, turning it on if it gets too high, although the ventilation has its own basic programming which usually works OK), and some nice extras like turning the Roomba and Sonos off when they're not used and turning them on at the right time, turning on my towel rail and so forth. I won't die if it doesn't work properly on any given day, but it annoys the hell out of me.

The cloud is clearly a source of some problems. I read here somewhere that there were technical difficulties with writing the variable and switch states to the box's memory - I don't know why that should be.

It's a work in progress. Let's see where we are a few months from now.

I also like the Zipabox concept, but it needs fleshing out. Native support for subroutines and string handling would be two things on my list.

I didn't mean to say that I don't know the difference between variables and switches. I meant that there's a difference in their behaviour when the Zipabox disconnects from the cloud - I wasn't clear. The variables seem to get their values copied back when the box reconnects, but the switches don't get their states back.

An example: If I use a "working day" variable in my rules, the rules always seem to work correctly.

David.

You wrote: "Is it possible that, when the system gets briefly disconnected from the internet, the variable values are correctly restored on reconnection, but the switch states are not? That's my guess.".

I have no idea. But I hope that they don't changes anything retroactive. That's creates mismatch.

However, if I use a virtual switch, the rules fail quite often. My guess is that it's because the box is disconnecting during the night before the rules run, but after the switch state is set.

(Now I set my switch states more frequently so with luck this problem will mostly go away).

Guys, just to check that I start to follow you correctly, every rule should be extended with the variable (ideally) so the rule will only start of the system is complete and not before.

So what I did is that I extended my simple automatic alarm rule with the variable that was mentioned by henry (restart rule). If i understand correctly this rule will now only start if the box completely restarted.

Is this the right approach?

Henry's rule (which I've copied) initially sets the variable Restart_Detector to 100 (the first time it runs). If the Zipabox then restarts, the variable will have some value other than 100 (let's say 0). I would imagine it would be always 0, but perhaps Henry is playing it safe, in case the variable gets set to 1 or something. So:

- 100 = Box has not restarted

- Not 100 = Box has restarted

Maybe there's something more to Henry's rule that I didn't understand. He'll have to clarify.

So the idea is to set up a rule which runs every minute, to check the status of this variable, and to reestablish the variable/switch values if there has been a restart. Once that has been done, you can run your rules as normal.

I think what Henry has is a switch or variable called something like "Variables Set Correctly". If the box is found to have restarted, "Variables Set Correctly" is set to "off". Then he triggers some rules to set up his variables and switches again. And then he sets "Variables Set Correctly" to "on".

Then, in each rule, he will have something like:

if (Variables Set Correctly)

Do rule stuff

Which deactivates every rule depending on whether the system has been correctly initialised.

Whether this is useful for you depends on whether your variables are set by a bit of logic derived from the day of the week, or the temperature, or whatever, or whether they are set because of something detected by a sensor. In the latter case, there's no way to get the sensor to send its input again!

What is setting the two switches in your rule? A movement sensor?

Here's an example of something you can't entirely fix after a reboot. In the Zipabox, sunset and sunrise are one-off events. You can use them to set a variable or a switch so that you know if it's daytime or nighttime, but if the value of your variable or switch is deleted, you're screwed. There's no way to recover the information. (That's why a "sunset time" and "sunrise time" constant puzzle piece would be very useful).

I have a rough-and-ready rule that corrects the "daytime" setting if the time is outside the time ranges that vary with season and daylight saving time (between 21:45 and 6:45 it's always night here, no matter what time of the year it is).

But if you're trying to track people's comings and goings with a movement sensor, there's no way to recover that information.

However: my experience suggests that as long as your box doesn't restart (if it just disconnects from the cloud momentarily), the variables will regain their old values on reconnect, whereas switches will get reset and *will not* regain their old values. Zipato say this is fixed in the new firmware, but I can't verify this yet.

So, for more reliability, I would use variables.

Hi David. Mi sensors are http sensors triggered by Tasker if I connect to my home wifi. Unfortunately it is not working 100% but that is Tasker fault not zipato. I understood Henrys restart topic to be configured to every rule so it is "safe".

Yes, his idea is to prevent rules from running if the variables/switches that they depend on are not set up correctly, so that they don't do anything stupid.

(I'm not Henry's spokesperson so he'd better correct me if anything I say isn't accurate!)

But if I don't use any variables or virtual switches in rules than how will this restart rule help to make the system more reliable?

I wonder if it would be possible to hardware flash a bigger memory in the box how it would help. I hope zipatile will be more reliable...

Could you perhaps get Tasker to periodically update the HTTP sensor with the connection state of each person? Rather than making it a one-off "xyz connected" event? That might solve 2 problems: Tasker's reliability and the switch state problem in the Zipabox.

In any event I would encourage you to try storing the state information in variables. I've found them more reliable. Providing that your Zipabox doesn't reboot spontaneously (like Henry's!), this should ensure you don't lose the state information so easily.

Question: can you trigger a rule with 2 switch states in that way? Does that work? I would have thought that the rule should be triggered by any change in either of the HTTP sensors:

when (ati doma any) or (maja doma any)

and then

if (ati doma off) and (maja doma off)

but I'm not sure.... I've never tried to incorporate 2 different triggers like that.

Hi David, thank you for your responses. It actually gave me good ideas how to make some workarounds

The rule itself works like a charm when it received the actual states. I will probably change Tasker so it periodically detects if is connected and if lost connection, wait 10 minutes and if the connection is not established, send the change.

OK, that's interesting. So if you set a rule to be triggered by 2 meters becoming inactive (or 2 switches being off?) the rule will be triggered when:

1) either meter or switch changes state

and

2) the state of both devices is inactive/off?

I didn't realise you could do that.

Yes, it does work like that.

David. I now testing the following:

1. i have a profile in tasker that when

connected to home wifi it changes the state of the virtual sensor to on

and if not connected state to off (via tasker http post). As I mentioned above, this is not 100%

working all the time so based on your suggestion I have

2. a simple recurring task in tasker

that checks every 5 minutes if Im actually connected to home wifi and

if yes, changes the state of the vistual sensor to on (meaning Im home)

and when not connected, sends a signal that im away. This way even if

task 1 is failed, zipato no later than 5 minutes will receive a change

of state of the virtual sensor.

Obviously I will need to do the same for my wife. Will know more in a couple of days...

Hi David, so far so good. If this truly works I can nearly forget to arm the system...

I like your presence-detection system. I might copy it!

let me know if you need the tasker printscreen how it is set up.

Yes please, that would be very helpful.

Ok. So I have 2 profiles.

1. profile checks a wifi state if the wifi is connected to my home or my neighbour wifi router. If yes, it will send https link to zipato virtual sensor ending with 1 (active). Exit task is wait 10 minutes and then send https link with 0 (inactive). As this profile did not work 100% correct, I have created another profile which simply runs every 10 minutes.

2. attached printscreen. First the task checks the current wifi ssid and writes it to a variable. Then if this variable equals of any of the wifi routers name (I have 3 different networks at home + 2 of my neighbours have) than sends the https link with 1 (meaning Im home). else it will sernd https link with 0. This way if my 1st task fails, no later then 10 minutes it will send info to zipato that i left home.

Apparently there is also a solution in tasker to simply wait for the response and if no response received, loop this as long as the response is received, but i dont know tasker that well.