HC2 switching everything ON by itself

[Ole 14]

Hi everyone!

 

I have a ticket going with Fibaro, but since this is a time sensitive issue and I haven't heard anything from them in about a week, I thought I could try the combined brain power of the forum as well. Here is roughly what I wrote to them to explain the problem:

 

"My home automation has started behaving very strangely. This past week every device has suddenly switched ON, all wall plugs, floor heating, lighting and both my awnings have been pushed out. Luckily there has been no snow yet and no wind, so the awnings have not been damaged. But if they are suddenly pushed out in heavy wind or with a lot of snow on the roof, they could be damaged. And when everything in my house switches on a lot of power is used so I need help to figure out what is going on.

I have no scenes that push my awnings out for example, but still they are pushed out and have done so three times this week."

 

It happened again this morning and I took a screenshot of the event panel.

 

And it does not happen at the same time every time. Could be in the afternoon, morning or in the middle of the night.

Please login or register to see this attachment.

[Sjakie 135]

Did you tried a rstore to a few days before the "magic" started?

//Sjkaie

[cag014 628]

Might be related to alarms (smoke, heat... or alarm defined by you)

I believe you didn't set any associations between devices... right?

[Tim__ 112]

Do you have HC2? There is a scene called zWave Monitor (search for it on this forum). You start the scene manually and it records all zwave activity for 6 hours. Will help you to see what is causing the issue.

[petergebruers 1,261]

10 hours ago, cag014 said:

Might be related to alarms (smoke, heat... or alarm defined by you)

 

I think you are on the right track (hehehe CAG014 and I have known each other for a while and have been doing this for years so no coincidence that we think alike)

 

But if it were a "alarm" frame then I'd expect some or lights of the relays to blink and not simply turn on, but it does depend on the device, impossible to say without more detail

 

So I am guessing it may have been a random collision or a rogue device sending an "ALL ON" command.

 

Older modules respond to this, newer do not, as a rule of thumb, because the "ALL ON" mechanism was deemed flawed and deprecated years ago.

 

FGS-211 double switch

 

Parameter No. 1 - Activate / deactivate functions ALL ON / ALL OFF.
Default value: 255
Options for changing parameter 255, 0, 1, 2
Available configuration parameters:
255 - ALL ON active, ALL OFF active.
0 - ALL ON is not active ALL OFF is not active 1 - ALL ON is not active ALL OFF active
2 - ALL ON active ALL OFF is not active

 

IMHO but not 100% sure a HC2/HC3/HCL *never* generates those frames (neither ALL ON nor ALARM)

 

If you own such a FGS222 then setting P1 to 0 makes this device "immune" to those events. I recommend that.

 

Similarly, the FGS222 has settings for alarms:

 

Possibility to change the configuration of the following parameters [30 – 33, 40 - 43].
0 - DEACTIVATION - the device does not respond to alarm data frames
1 - ALARM RELAY ON - the device turns on after detecting an alarm 2- ALARM RELAY OFF - the device turns off after detecting an alarm 3 - ALARM FLASHING - the device periodically changes its status to the opposite, when it detects an alarm within 10 min.
Parameter No. 30 - General Alarm, set for relay no. 1.
Default value: 3[byte] ALARM FLASHING
 

I am not sure if there is an easy way (without Zniffer) to determine the source of this because the HCx you have may very well ignore this type of packet, so you only record the *effect* of such frames but no which module caused it.

 

Do you own RGBW version 1 modules? Are they fw 27.27? That is a now troublemaker if the are 26.26 or older and in that case it is all about "rogue associations"

 

 

Lastly... I am not sure you can do this on a HCX but some other controllers allow you to enter "255" in associations. That is not a real node ID but a broadcast address and all nodes will respond to what that association does (eg send temperature changes, or basic on/off)... I've seen it happen. It is very rare.

 

[Ole 14]

14 hours ago, petergebruers said:

 

I think you are on the right track (hehehe CAG014 and I have known each other for a while and have been doing this for years so no coincidence that we think alike)

 

But if it were a "alarm" frame then I'd expect some or lights of the relays to blink and not simply turn on, but it does depend on the device, impossible to say without more detail

 

So I am guessing it may have been a random collision or a rogue device sending an "ALL ON" command.

 

Older modules respond to this, newer do not, as a rule of thumb, because the "ALL ON" mechanism was deemed flawed and deprecated years ago.

 

FGS-211 double switch

 

Parameter No. 1 - Activate / deactivate functions ALL ON / ALL OFF.
Default value: 255
Options for changing parameter 255, 0, 1, 2
Available configuration parameters:
255 - ALL ON active, ALL OFF active.
0 - ALL ON is not active ALL OFF is not active 1 - ALL ON is not active ALL OFF active
2 - ALL ON active ALL OFF is not active

 

IMHO but not 100% sure a HC2/HC3/HCL *never* generates those frames (neither ALL ON nor ALARM)

 

If you own such a FGS222 then setting P1 to 0 makes this device "immune" to those events. I recommend that.

 

Similarly, the FGS222 has settings for alarms:

 

Possibility to change the configuration of the following parameters [30 – 33, 40 - 43].
0 - DEACTIVATION - the device does not respond to alarm data frames
1 - ALARM RELAY ON - the device turns on after detecting an alarm 2- ALARM RELAY OFF - the device turns off after detecting an alarm 3 - ALARM FLASHING - the device periodically changes its status to the opposite, when it detects an alarm within 10 min.
Parameter No. 30 - General Alarm, set for relay no. 1.
Default value: 3[byte] ALARM FLASHING
 

I am not sure if there is an easy way (without Zniffer) to determine the source of this because the HCx you have may very well ignore this type of packet, so you only record the *effect* of such frames but no which module caused it.

 

Do you own RGBW version 1 modules? Are they fw 27.27? That is a now troublemaker if the are 26.26 or older and in that case it is all about "rogue associations"

 

 

Lastly... I am not sure you can do this on a HCX but some other controllers allow you to enter "255" in associations. That is not a real node ID but a broadcast address and all nodes will respond to what that association does (eg send temperature changes, or basic on/off)... I've seen it happen. It is very rare.

 

Hi and thanks for all of your feedback so far, it is really appreciated.

 

I do in fact have two FGS-211 and one FGS-222 relay switches, the FGS-211s are used for floor heating (but one of them is almost always switched off) and the FGS-222 for ceiling light. I have made the recommended changes to the parameters for all three and it will be interesting to see if that fixes it. They have always worked, unlike a number of other devices, so I have never suspected them of causing any problems. But given this information it occurs to me that this problem is by far at its worst when it is cold and I only use the FGS-211 floor heating when it is cold. I have a scene that switches the heating in the floor on and off every 30 minutes, could that be the issue when used with this device without the recommended settings? To start, I have disabled the scenes that switch them ON and OFF to see if the problem disappears. If so, I will try to enable the scenes again and see if that also works with these new parameter settings.

 

Cheers!

[Ole 14]

Hi!

So there has been little development with my issue. Fibaro support haven't provided any help and have stopped replying to my questions. I have sent them several logs but nothing came out of that. So I am left to try and find the cause myself, hopefully with continued help from you guys which is much appreciated.

 

I was unsure wether you @petergebruers meant the devices FGS-211 and FGS-222 could be causing the problem or that they would be affected by it. They were at least affected so I ended up disconnecting them to try to eliminate that possibility while trying to find the cause. In any case the problem is still there with these three devices disconnected. Then I looked into the possibility of it being the door sensors I have in the garage. Looking at the manual it says that the operating temperature is 0 degrees C and up. Since this problem is way more frequent in winter I thought perhaps that could be it. I therefor removed the batteries in those two devices as well, but the problem is still there.

 

The only devices I have left that are exposed to sub zero temperatures are two Vision sirens (still indoors), but according to the manual they have an operating temp of -15 C to 60 C and it's rarely that cold where I live. But I will remove the batteries all the same.

 

 I am unsure how to proceed. I guess I could start ripping out all devices, one room at a time, but then the z-wave communication might start causing problems as well? Any thoughts on what to try next?

 

Thanks!

 

 

Edited January 17, 2022 by Ole
typo

[petergebruers 1,261]

2 minutes ago, Ole said:

I was unsure wether you @petergebruers meant the devices FGS-211 and FGS-222 could be causing the problem or that they would be affected by it.

"affected" is the right answer. The relay's simply respond to a packet they've received. You can change parameters to make these receivers insensitive, I posted details a few posts back. But that's a bit "working around the problem".

 

4 minutes ago, Ole said:

I am unsure how to proceed. I guess I could start ripping out all devices, one room at a time, but then the z-wave communication might start causing problems as well? Any thoughts on what to try next?

Yes "ripping out modules" (ie unpowered them or exclude them) is the poor man's solution but may take a long time (weeks or longer in this case) and indeed cause other problems (with routing)

 

You need a Zniffer. I've been using this tool for years and I've recommended to more than 20 users. It takes some skill but AFAIK all owners have at least understood their problem and in most case they've also solved the problem(s).

 

Please read this topic, Alex can better explain than me, why it is your best option...

 

 

[Ole 14]

On 1/17/2022 at 10:58 AM, petergebruers said:

"affected" is the right answer. The relay's simply respond to a packet they've received. You can change parameters to make these receivers insensitive, I posted details a few posts back. But that's a bit "working around the problem".

 

Yes "ripping out modules" (ie unpowered them or exclude them) is the poor man's solution but may take a long time (weeks or longer in this case) and indeed cause other problems (with routing)

 

You need a Zniffer. I've been using this tool for years and I've recommended to more than 20 users. It takes some skill but AFAIK all owners have at least understood their problem and in most case they've also solved the problem(s).

 

Please read this topic, Alex can better explain than me, why it is your best option...

 

 

Thanks!

 

I have added both scenes (monitor and viewer). Is there a way to save this information so I can look at it full screen in excel or something?

 

Anyway, I saw a few devices that had way more traffic than others (wall plugs, that have worked fine) that had the spinning icons on all parameters. I have done a soft reconfigure on them and the traffic load seems to be more normal now. Could that cause my problem of other devices being switched on all of a sudden? Or would they just cause unnecessary load on the HC2? I have added a couple of screenshots. If I could export the data it would be easier to view and share the tables.

 

 

 

Please login or register to see this attachment.

Please login or register to see this attachment.

[Ole 14]

Unfortunately it happened a few times again this afternoon, so clearly didn't help reconfiguring the units I looked into. There is another thing that happens that I haven't noticed before and that is that my Fibaro for iPhone app suddenly has about 40-50 notifications on its app icon. Of course when I launch the app and go to notifications, there is nothing there. See attachment.

 

 

Please login or register to see this attachment.

[petergebruers 1,261]

20 hours ago, Ole said:

I have added both scenes (monitor and viewer). Is there a way to save this information so I can look at it full screen in excel or something?

I am not very familiar with the "monitor and viewer" but you can ask me anything about Zniffer. The monitor was written by @cag014 and has the advantage of being very easy to start with, but it can only see what HCx sees which is less (it is filtered) than what Zniffer can pick up.

It is good at detecting "spamming devices" which can cause issues, so it is a good start

 

20 hours ago, Ole said:

Anyway, I saw a few devices that had way more traffic than others (wall plugs, that have worked fine) that had the spinning icons on all parameters. I have done a soft reconfigure on them and the traffic load seems to be more normal now. Could that cause my problem of other devices being switched on all of a sudden?

If you have a lot of traffic (I would quantify that as "bursts of 10 commands per second") then weird things can happen like random, valid packets appearing and causing trouble.

 

I rather fanatically "turn down reporting" to keep my largish network sane... I one wrote a script to assist with setting parameters on most Fibaro devices, I didn't mention it before because it is unmaintained. On the other hand, imho more recent devices cause less trouble (or have better defaults for bigger networks) so you might find it useful:

 

 

17 hours ago, Ole said:

my Fibaro for iPhone app suddenly has about 40-50 notifications on its app icon.

I don't own an iPhone and I am not familiar with that issue...

[Ole 14]

Ok, I will try and get my hands on a zniffer to get to the bottom of this. Thanks!