This object is in archive! 

How reliable Zipato is?

Markus Viitala shared this question 7 years ago
Need Answer

I have just recently bought my Zipabox and yesterday I could not remotely switch off or on my sockets. I think that WebApp service were down etc.? How often this kind situations happen?


I have plan to host remotely my summer cottage heating, but I want it to work very reliable! No I feel that I can`t trust this system! :( It locates 130 km from my home and it would be nightmare if heating stays always on!


Previously i just had simple GSM-socket and it did work nicely...

Replies (19)

photo
1

Reliability of system depends of all components of the system and the configuration of the system. You were not able to remotely control the heating for some time now due to the issue which we had with Amazon servers. Sometimes you may not be able to do it due to some issue with Zipato software which will require us to restart the servers. In general, all these issues are possible and they will cause some short delays/outages. So if you realy need to ensure 100% availability of your summer house, you should rather consider some professional system with monthly subscription, Internet backup and on site intervention support. I know there are many companies providing these services for around Euro 50.-/month already.

photo
1

There is no solution that can ensure a 100% availability.

Zipato is improving it's stability and if you take care of replicated IP access it is fairly safe.

photo
1

Also if you're Rules are pogrommed well you don't have to worry about broken Servers or Internet Connection.

Like yesterday, my complete home automatization was running fine like every day...

regards Helle

photo
1

Rules do not help if I suddenly want heating on before hand...

photo
photo
1

Ok, but how often this kind like yesterday had happen earlier?

photo
1

WebAbb should also tell that it cant control system remotely. I managed to switch plugs on and off at WebApp, but at real live nothing happened... State of the switch should be always same than real live or app should tell that it do not cant connet to BOX.

photo
1

To answer you question: For me it was the first time I, I had server issues and I use zipabox for about a year now.


All the other times when people had problems with zipato servers, my box (in Germany) could be reached without problems. Most things work without internet connection, but of course you can´t change rules and you can´t remotely switch devices. I didn´t think much about that because I have a backup (e.g. one remote control in the flat where the system is installed) to switch everything off) but I forgot one device which is only accessable via alexa.... I just put that into the rule of the remote control as well. But that would´t help you either.

photo
1

Markus,


I have been a Zipato user for over two years now, as Sebastian said if you need a 99% reliable controller you will have to look for professional monitoring systems that do not use Zwave, this network it is not to use on life/death scenarios as stated in the zwave alliance page, nor any system that uses it. In my two years + of working with Zipato I have experienced 2 or 3 outages like this one, there has been other issues that have been misinterpreted as server issues which afected the functionality in the system, however I think it is reliable enough for your application if you configure it right (keep offline checked).


During yesterday issues my controllers were working, even interlocks between Zipatile and Zipabox through local network, of course any cloud related function didn't but my rules kept my house working, I have to say 1.2.15 firmware has improved speed and reliability of Zipabox.


Maybe rules cannot take in consideration any scenario, but it depends a lot of how you program your box to the number of scenarios taking in consideration. Im confident that these issues will be even more rare once all the big changes are stable (cluster, backup, SIP server).

photo
1

On the whole I find it pretty reliable. As I have ironed out problems in my rules, I've found that most things work as intended, day in, day out.


But: I have specifically programmed my rules to be tolerant of a loss of state in the box. In other words, I don't set a variable or switch once and then expect it to retain that state all day and then run my rules off that state; instead, I constantly recalculate the states I need. So, rather than set a "daytime" variable once at sunrise and again at sunset, I have a rule than runs every ten minutes that sets the daytime variable according to whether it's after sunrise and before sunset. I do the same with all my other variables. This means that, if the box restarts (in my case this happens quite frequently), or loses its variable states for some other reason, it will quickly recover and continue working as expected.

photo
1

Hei David.

Do you use a virtual switch that tell other rules if there is day or night? And then a rule that check with astro every 10 minutes and change the virtual switch accordingly?

Can you post the rule?

I thought also virtual switches ran on the server, but they are running locally?

And yes, the beta 1.2.15 really works good. Everything is much faster and smoother.

photo
1

Hey there Dag,

I use variables rather than switches. Firstly, I have a ton of them (well over 100), and they're much less resource-intensive than switches. Secondly, their values are globally available in all rules. Virtual switches seem to have a state that is local to each rule. So imagine: rule 1 triggers rule 2, that alters the "daytime" switch, and then rule 1 tests the state of the switch. Unless you call "refresh all", it will still see the *old* state of the switch. Thirdly, switches experience delays in changing state. So if a rule changes a switch state and then immediately tests its state, it will not see the new state, but the old one! Because the state change hasn't happened. So you have to sprinkle "waits" all over your rules to handle this. Variables don't have this problem - they change state immediately. So, I recommend using variables.

This is my rule. I also have the standard rules that run at sunrise and sunset, but this rule runs every ten minutes and corrects the state in case it gets lost due to a restart or whatever. There is more to it, but it's detail that's not important here. The last check is a "sanity test" which is probably not necessary - just in case the Zipabox sunset/sunrise data is screwed up or not set and is has the value of 0.

photo
1

Doesn´t that put a lot of workload on the box? I prefer virtual switches (they keep their status) and set them twice a day and after a reboot. Haven´t had any problems with that so far (First rule is triggered twice a day (sunset/sunrise) and sets the virtual switch or sensor to day or night and the second rule does the same after a reboot. Until now it worked fine for me.

photo
1

For the reasons I explained, I think variables really are a better option. As for the workload, I have around 50 rules which set well over a hundred variables running every 10 minutes, and the box handles it just fine :-). Most of the variables depend on values that change over time, e.g. time, temperature, cloud cover, etc. etc., so they need to be regularly recalculated.

photo
1

The only reason why I don't use variables too much is because you cannot start rules with them (which doesn't make sense to me), That is why I stick with virtual meters.

photo
photo
1

"and has the value of 0". Can't edit my comment for some reason.

photo
1

@David: Very interesting solution although I only understand it partly. In addition I can only see a part of the rule. How do you use the variable "daytime" in your rules?


@Markus: I am using the Zipabox for over two years now. In my opinion it is getting better and better, meaning more stable and reliable. Nevertheless there is always something to correct or improve. Last issue I had were some Controllers which suddenly disappeared and I had to re-include them.

The most unreliable things concering the Zipabox are the timings and features provided by Zipato for new features, improvements, etc.

photo
1

I just test for daytime = 0 or daytime = 1. See screenshot.

The rest of the rule just calculates minutes since sunset, minutes since sunrise, minutes until sunset & minutes until sunrise. I use these in other rules.

photo
1

My internet connection is down as we speak, and my doorlock is not auto locking anymore. My three thermostat pro are not working, so the house is cold. Too bad if this happens in two weeks time, when I am going on vacation abroad.


It is just not trustworthy. And I am not able to log on to the box locally, like I did before.


Last time I lost internet the same thing happened to my thermostats while I was at work. And Zipato still claims that the system works with no cloud... That is probably the intention, but in reality I cannot use it to control important functionality like heating. It will eventually lead to frozen pipes and water leakage.

photo
1

Do you have the "keep offline" checkbox checked on your controller? Are you depending on virtual weather station (astro feature) for triggering autolocks?

photo
photo
1

Dear Marius,


I've a different experience to your one. If my house lose internet connection my Virtual Thermostats keep on doing their job correctly. Simply and obviously I cannot connect remotely but locally the house is under control.

photo
1

I wish it would work for me too, because overall I like the system. I am investigating other systems that are not cloud dependent, and my first impression is that they are "high maintenance". So I guess the perfect system does not exist... Yet! 🙂

photo
1

Recently I had no Internet at all for four days due to some stupid street workers ..... The Zipabox worked liked always, no Problems at all. But of course, as soon as you want to change something you cannot reach the ZipaBox. I have now setup my 3G dongle correctly (still have it one year but never the time to check it) and it works pefectly as soon as the internet connection is down. It is much slower, but who cares in such moments about that .,....

photo
1

For that reason I prefer to have a thermostat with a standard schedule which will continue to work just fine even if it loses internet access, and then have the Zipabox rules simply tweak the thermostat settings when necessary - for example, when I'm unexpectedly at home or unexpectedly out.


I wouldn't want to have my home heating depending 100% on the Zipabox.

photo
2

Zipato has two main unresolved issues that make that solution unreliable. One is problem with forgetting z-wave devices without user action. In other words zipato under unknown circumstances can remove your device from z-wave network and you have to reinclude it by yourself. This is number one killer issue, as it happens randomly, quite rarely (at least in last few months) but is very laborious to fix as it requires including device and fixing all scenes that contained lost device.

Second is random box resets. This is less problematic, but introduces lot of work to create scenes, as zipato doesn't remember virtual devices states for scenes after such reset. So in UI devices have last known states, but for scenes they are all nulls. You can imagine, that you might set virtual sensor Me.AtHome = true and have no rules triggered that require you being at home just because a box restart happened recently. And when you look to the app everything seems ok.

Both those problems were reported to Zipato team several months ago with no solution by now.

Leave a Comment
 
Attach a file