Multiple Fibaro Wall Plugs FGWP102 keep getting excluded from the network unexpectedly

[robbert]

@chris

If by “phantom” you mean ghost node

No - associations that don’t exist. Eg if yo configure an association between device 2 and 3, then remove node 3 from the network and don’t remove the association.

Very well - as I do not use associations a lot, I am fairly sure these shouldn’t be there. But I will double check.

@chris

Maybe the device has a fault and has reset. This seems most likely now.

It has, second device in a row, on the same spot.

@chris

It’s always useful to provide all the information you have - if you’d mentioned this initially that the device is in a reset state, then we may have had a different prognosis.

You are right that I did not mention this when posting the second occurence of the issue, however when the issue first occurred I did describe the trouble I had fixing the node, from which can be concluded the device was in a rather confused state, not just temporarily unreachable.

@chris

It is however still included in the network as far as the controller is concerned (I assume?)

Yes, that’s what I wrote in my other reply in this thread. I had to set the node as failed and remove it using PC Controller.

@chris

If you restart the controller, is it listed in the nodes list?

Unfortunately I can’t check this any more as I have already removed the dead node.

@chris

Again, you have more information than me.

Based on the little information I had when I made the comment, it looks perfectly like interference - working one minute, and not the next. If you had said that the device has reset to factory state, I would have provided a very different response. I would generally expect it to return, but if it is now excluded from the network then that is a whole different issue.

I guess partly the “more information” you are referring to is already present in my other responses in this thread, and from those it can be concluded that this problem isn’t likely to be regular interference.

However, I realize I could have mentioned the device’s state in my follow-up response about the second occurence as well. I’m sorry for that missing piece of info and I will do my best to be more clear in future.

Thanks for your help as always.

[robbert]

@robmac

and certainly two devices

Exactly, this is the weird part.

@robmac

I think if I read the post correctly earlier one was removed and a new one put in the same place but symptoms continue.

This is correct.

[chris (Chris Jackson)]

@robbert

Exactly, this is the weird part.

Again - I would suggest a word of caution! Don’t jump to the assumption that it is the same issue. It might be, but the number of times I see people make assumptions like this that force them to make prejudged decisions that are later shown to be incorrect is quite high.

It’s useful to consider, but I’d really not make any assumption at this point.

[robbert]

@chris

Again - I would suggest a word of caution! Don’t jump to the assumption that it is the same issue. It might be, but the number of times I see people make assumptions like this that force them to make prejudged decisions that are later shown to be incorrect is quite high.

It’s useful to consider, but I’d really not make any assumption at this point.

We are on the same page, Chris. I definately agree with you, we shouldn’t jump to any conclusions.

I know I have been having issues in this spot for a while now, and have the feeling that all these events are related to the same issue. But a feeling does not help much, that’s why I recently started monitoring/logging this.

I now have permanent debug logging on and a Zniffer coming in, so time will tell…

Thanks for your help so far, @chris, @robmac, @Bruce_Osborne!

[robmac (R Macdonald)]

@chris

No - associations that don’t exist. Eg if yo configure an association between device 2 and 3, then remove node 3 from the network and don’t remove the association.

The phantoms on these devices are even weirder than that. A device with no association suddenly has node id 315 as an association for example.

Yes I know only 232 should be possible but there is a definite issue in these and a few other fibaro devices. Sme NVM corruption at a guess.

They do not show in openHAB interface but if you query in PC Controller you see them.

You will see odd packets in Zniffer though when the device generates reports for a node it should know nothing about with possibly an out of range id.

[chris (Chris Jackson)]

@robmac

A device with no association suddenly has node id 315 as an association for example.

I can’t see how that is possible. Firstly, node IDs are a single byte - 8 bits as stored. This only physically allows numbers up to 255.

@robmac

They do not show in openHAB interface but if you query in PC Controller you see them.

I don’t know what query you refer to? Do you mean getting the list of nodes, or what?

[robmac (R Macdonald)]

@chris

I can’t see how that is possible. Firstly, node IDs are a single byte - 8 bits as stored. This only physically allows numbers up to 255.

Indeed by design but by Polish programming odd things happen. c is such a raw thing . With multiple endpoints who knows how they have managed to get it wrong. Combine endpoint and nodeid badly???

@chris

I don’t know what query you refer to? Do you mean getting the list of nodes, or what?

The association tab. I think I have an image of one somewhere. I will see if I can track it down.

[chris (Chris Jackson)]

@robmac

by design

Well - by physics really. If there’s only 8 bits being used, then it can only be a number between 0 and 255. Anything else is a display problem as a byte can ONLY hold that number.

@robmac

I think I have an image of one somewhere.

That would be interesting.

I would be careful not to assume there is no bug in the Sigma software either That said, if it’s showing something like that, then there is clearly a problem elsewhere as well.

[robmac (R Macdonald)]

@chris

Well - by physics really. If there’s only 8 bits being used, then it can only be a number between 0 and 255. Anything else is a display problem as a byte can ONLY hold that number.

there is a bit of memory and only 8 bits should be written and read. nothing physical. This is c not a nice protected language.

It is so bizarre that nobody believes it can be

@chris

I would be careful not to assume there is no bug in the Sigma software either That said, if it’s showing something like that, then there is clearly a problem elsewhere as well.

I have no illusion on that. Some of the comments in the code that is available are fun.

I will search the old thread on this. Original Fibaro RGBW was main culprit but these modules do it to.

[chris (Chris Jackson)]

@robmac

there is a bit of memory and only 8 bits should be written and read.

I’m still not really sure what you’re referring to, so it’s a little accademic. At the end of the day, if it’s 8 bits, it can’t hold a larger number and that is independent of the language. If it’s displaying a larger number, then that could be a bug in the display/interpretation of the information.

@robmac

It is so bizarre that nobody believes it can be

chris:

Nobody believes WHAT can be? An 8 bit number will physically only use 8 bits and can only store 0-255. There can be a bug in any language to display something different, but if the protocol, or memory allocation only physically allocates 8 bits, the it can physically only store a number from 0-255 as there is no room for anything else.

Apologies if I’m misunderstood your point here.

[robmac (R Macdonald)]

@chris

Apologies if I’m misunderstood your point here.

You have

You assume it is a language with a byte data type that is all managed but it is c and the programmer might just have malloc a bit of memory and then made a mess of the boundaries.

In PC program they may have been lazy and just made it an int but who knows in the firmware other than the fibaro dev. You also assume that the pointer is not corrupt and pointing at the 8 bits that was allocated rather than some totally different bit of memory

[chris (Chris Jackson)]

@robmac

You assume it is a language with a byte data type

No - I’m assuming that the protocol defines this as a byte. A byte is physically 8 bits and can only carry numbers of 0 to 255.

That’s why I said earlier that programs can have bugs, but the physics of a byte, and the allocation of a byte to a protocol can not provide a number of greater than 255 in a byte. That’s physics.

Anyway, it doesn’t really matter so I’ll close my input on this thread.

[robbert]

So, I just managed to deliberately reproduce this issue (or: these symptoms).

Current OH version: 2.5.2 (release).

I reproduced this issue by quickly toggling the wall plug (while connected to some LED lights), on and off multiple times. EDIT: toggles were performed from the OH web UI and not using the physical B button. After doing this for a while, things start lagging, and eventually the device goes offline. These effects are not suprising thusfar. However, now the device thinks it’s not included to the network anymore (signaling a red ring when plugged into the socket).

Note: Obviously I know that switching on/off quickly multiple times is not very normal user behaviour, but this problem also happens under normal usage (it only takes longer to trigger).

Anyway, the plug is now offline/excluded. Except for unplugging/replugging I haven’t done anything yet to fix it. If someone wants me to try something, let me know.

Logs are here.

At 16:24:03 it went offline, and then came back online at 16:25:01 after just replugging it.
At 16:30:54 it went offline again, and now it thinks it’s excluded.

Does anyone have any ideas as to why this happens?
Suggestions for me to try?

[Bruce_Osborne]

That is normal behaviour. From the manual:

Exclusion Information To remove the device from the Z-Wave network:

1. Plug the device into a socket nearby the main Z-Wave controller.
2. The LED ring will glow green signalling being added (removing is not necessary otherwise).
3. Set the main controller into remove mode (see the controller’s manual).
4. Quickly, triple click the B-button located on the casing.
5. Wait for the removing process to end.
6. Successful removing will be confirmed by the Z-Wave controller’s message.

[robbert]

@Bruce_Osborne

Quickly, triple click the B-button located on the casing

Note that I didnt touch the B button. These are commands sent from the web UI.

[robbert]

Update: I have been continuing to troubleshoot this issue together with @robmac and @petergebruers (thanks guys!). Eventually I contacted Fibaro as we suspected an issue with the device firmware (or design). Fibaro have now acknowledged that indeed there is an issue and have notified me that they are working on a fix.