Devices intermittently not switching on/off

[Scotfree 0]

Hoping someone might have advice. I've recently experienced relays not switching on/off intermittently. These have been working for a year or so and it just seems to have started.

Sometimes one relay with a lamp connected to an FGS221 does not turn on. Sometimes another FGS221 does not turn off. Sometimes an everspring relay does not turn on. Last straw was when my boiler FGS221 did not turn the hot water on this morning but a manual switch-on worked.

Anyone any idea what is going on ? The z-wave range does not seem to be an issue as this has just started to happen. On V3.591 beta.

[MalvinYNJ 4]

Do a reboot on your hc2?

[Starbug 0]

I had a similar problem mainly with the Fibaro dimmers of which I have a few recently however it was with a much newer install and seemed to start around installing about 50 of some 80 z-wave devices. I contacted support and they seemed to think it was due to my danfoss valves and they recommended i switch them off. I did not go that far I started by setting the wake up times for each device to be slightly different and also increase the wake up time from about 400s to anywhere between 600 and 1200. This helped a bit but I don't think this was the real cause. I narrowed down the final cause i think to having some one of two things. I relocated the HC2 to a more central point in the house but also I disabled the XBMC plugin I was using with the HC2. I feel it was more the XBMC plugin that was causing the problem but all seems ok now. Maybe something similar with your setup to consider? Anything new in terms of scenes or any new device added?

On a similar point I see one with the dimmers in a few rooms. When I switch the dimmer on locally at the switch on the rare occasion the switch dos not work it takes maybe 3 or 4 presses for the dimmer to switch on. Vary strange and only happens rarely but when it does its annoying.

[1152 33]

Have experienced same problem.

Relocated my HC2 vertically from the cellar to ground floor and horizontally from the edge to the center. Also located it about 30 cm from my new ASUS RT-68U WLAN router (the z-vawe antenna about 15 cm higher than the 2,4/5 ghz antennas of the router).

Aldded a few devices, so now the total is more than 50 physical devices.

As said: Now from time to time devices intermittently not switching on/off, and possibly also more often a dead node

[waveuk 0]

I have a similar problem but with scenes. Some times scenes do not switch on/off the lights but I can do it from my mobile. Based on this I think my problem is not with the network but HCL software.

[robmac 173]

I can not speak for the HCL but HC2 definitely gets in a state where, if the network is very busy or slowed down due to poor connectivity or a device going off line, the z-wave queues can fill and become deadlocked.

It then sometimes takes a minute or two to timeout and work again and sometimes with the loss of a couple of commands.

I have tested it extensively and can force it to happen by upping the traffic by reducing wake times and increasing regularity of polling and reports.

I have also experimented and find I can cause the issue with a bad script that chatters across the network or the api, main loops in virtual devices doing many calls to api, external code bombarding the api or too many looping scenes with calls to the api.

I have tried many times to get the track progress from my media system to show on a virtual device but every way I try makes the system less stable and loose events. OK with one music player but when I have 14 playing all updating their virtual device I start to get the issues unless I reduce the update to 30s intervals. OKish for movies but no good for music tracks.

So a few ideas:

Make the connectivity as good as possible

Increase the polling interval

Reduce the reporting interval of all devices temperature, power etc.

Increase the wake interval

Check any modules you have calling the HTTP api are not flooding the HC2 with chatter

Check any virtual devices and particularly main loops for chatty calls. (Try putting some of them in an if so they only call on first run of the loop not every time)

If you have to use scenes with loops make sure the sleep inside is long enough and ideally work out how not to loop.

also

I read on here that block scenes run LUA under the covers so you may also have many loops without realizing it. If you have many scenes configured to do something at a time of day that would be the case. Fibaro may care to correct this.

[Starbug 0]

Thanks Robert, your extensive experience certainly backs up what I have been finding out myself recently.

Would adding a second controller help in this regard in terms of spreading the load of scenes?

I guess multiple controllers is not going to help if to much z-wave traffic on the network is the problem right?

Do you know if Fibaro are likely to improve any of this in v4 in terms of protecting z-wave communication

Thanks!

[robmac 173]

Thanks Robert, your extensive experience certainly backs up what I have been finding out myself recently.

Would adding a second controller help in this regard in terms of spreading the load of scenes?

I guess multiple controllers is not going to help if to much z-wave traffic on the network is the problem right?

Do you know if Fibaro are likely to improve any of this in v4 in terms of protecting z-wave communication

Thanks!

I may go multiple controllers when a good 4.x release is around. Just holding the investment.

I think it would help my network and others have reported success. I think one of the pro installers indicated that they have installed like this.

The power of the extra controller is an issue though that I need to look into. The other option is that the 500 chips have a greater transmit power so a bigger network with less routing so in many ways more likely to solve our issue. One reason a HC3 might be a welcomed addition to the Fibaro range for me!

On a split of network, if you think logically about the challenge we all have, in a large house with big network it is not surprising that the low power z-wave chips in the modules slow up under traffic. It is inevitable that some will become routing bottlenecks and traffic possibly take seconds rather than sub seconds to traverse. So I have to agree with you that it is not guaranteed to fix but if you split the network into two homes assuming limited interference it should be better.

Taking a step back and considering the challenges of HAS. I would suggest all this is part of the design compromise of z-wave to make them low power. If you had 200 nodes all drawing 5w your power bill would be your concern not the reliability of your network. i.e. 1kw 24 hrs a day just for your nodes!

Current chips also work under multiple bit rates for backward compatibility.The multiple bit rates I believe is improved in new chips as I believe the current chips take it in turn to listen on the legacy rates where the new listen on all rates all of the time. I always try to use units that use the newer bit rate. Not sure it helps but it makes sense that it may as handling messages under different rates might slow the network.

Remember z-wave only transmits at very low energy so we shouldn't expect it to penetrate much. I think the new 500 have a bit more and have saved power in other areas. The chips also go into an idle low energy state most of the time to cater for the normally low utilisation so it is designed all round to use very little energy and newer chips will be even more frugal.

Before you jump from Z-Wave, Zigbee is even less capable with regards range because while it uses a similar transmission power the frequency employed reduces the range but that is a separate and very complex debate. Normal wi-fi just burns energy but is great for what it should be used for. A point those that are busy integrating some very prety devices that use wifi into their HAS may want to consider.

So why all these rambling? Well it leads to why we all possibly have issues.

I think Fibaro HC2 is possibly a bit sensitive to these slowdown in current form. Possibly Fibaro assumed the z-wave chip queue was big enough and did not programme well around it filling up when the network is busy with some return messages slow to come back. Hard to tell but that would fit the symptoms.

I have no inside track on what they are doing but there was a comment on the Alpha about changes to the threading so I hope they will fix.

Also unlike some others I would welcome a HC3 with the new chipset or a paid upgrade for my HC2.

Progress is good or we would still be using bell pulls and aberrant ancient practices to automate our homes.

[diderik 6]

I had a similar situation yesterday evening. The "going to bed" scene switched off everything apart from a table lamp (connected to a wall plug). The device had disappered from the HCL, so I couldn't turn it off from there either. The wall plug is associated to a double relay controlling a ceiling light, and when manually switching on and then off the ceiling light, the wall plug switched off. This morning, the wall plug was back in the HCL.

Update 25.06.14: For the first time ever, this was actually my mistake. Sort of, at least. I had this problem:

Please login or register to see this link.

I exclueded and included the wall plug in question, and didn't realize i needed to update the scenes even though the devices had the same names &c.

Sorry for the confusion...

[DT_p 0]

Thanks God I'm not alone!

I have the same problem and it's happened from one day to another...

Very strange all my devices are disconnected and when I try to reconnect sometime they are work sometimes no. The support didn't help so much. My feeling is that is something to do with the new iPhone and iPad update software.

[Starbug 0]

I was having a lot of delayed z-wave transmissions or no transmission at all. It was very random in when it occurred (but happened constantly) and with all scene's disabled it still persisted. For example I could click on a fibaro dimmer in the web gui and watch the front of the HC2 and not see any z-wave led flash on the unit. I would click the device again and still no transmission and the device would then show up dead. When I woke the dead device it then would start working. The intresting thing is that devices sending data to HC2 worked ok while that was happening say for example a door/window sensor would update its status. This was happening for all devices at the same time so very much the whole z-wave transmission from the HC2 had locked up or something. Then suddenly all lights would respond like a minute later as though all the commands were suddenly sent at once.

Anyway the fix for me is that I have moved to the Alpha 2 software which so far i have not had the issue. I think this build has a better z-wave engine and as most of my devices are fibaro its stable for me.

[alex88 70]

I am experiencing something similar for at least four Fibaro Dimmer modules. Sometimes the ligthts turn on first time sometimes it takes 2 or 3 clicks.

I am in the process of first replacing the switch mechanism then the Dimmer modules to debug what the root cause is.

Until I had read this thread I had assumed it was down to faulty switches. It looks like that may not be the case after all.

[alutke 0]

I have the same problem, all modules are delayed. Sometimes even not work.

I have the HCL, the modules function to squeeze the keys, but through the app and the browser no longer hang.