Fibaro woes redux

Catman · February 23, 2019, 4:28pm

So after support failed to fix it last time and just ignored me, I excluded and re-included the Fibaro FGBS321 again.
This was about 6 weeks back at most.
Again one of the temperature sensors has stopped responding, but this time the logs might be a bit different:

24 02/23/19 16:23:03.660 ZWaveNode::HandlePollUpdate node 35 device 116 class 0x31 command 0x5 m_iFrameID 182/18968120 data 0x1 0x44 0x0 0x0 0x5 0x46 (#D###F) <0x77172520>
02 02/23/19 16:23:03.660 ZWaveNode::HandlePollUpdate node 35 device 116 skipping bogus class 0x31 <0x77172520>
24 02/23/19 16:23:03.660 ZWaveNode::HandlePollUpdate node 35 device 116 unhandled class 0x31 command 0x5 data 0x1 0x44 0x0 0x0 0x5 0x46 (#D###F) <0x77172520>

Anyone got a clue what that means and if it can be fixed?

Cheers

C

rafale77 · February 23, 2019, 5:04pm

No idea why the vera firmware can’t handle this command class. It is so well documented here

http://wiki.micasaverde.com/index.php/ZWave_Command_Classes

Command class 0x31 is a multilevel sensor. COMMAND_CLASS_SENSOR_MULTILEVEL.

I looked up some of my Vision 4 in 1 sensors and they show the same command class as unknown… yet the temperature works just fine,

NodeInfo: 0x31_V7-Unknown Class 0x59-COMMAND_CLASS_ASSOCIATION_GRP_INFO 0x5A-COMMAND_CLASS_DEVICE_RESET_LOCALLY 0x5E-COMMAND_CLASS_ZWAVEPLUS_INFO 0x70-COMMAND_CLASS_CONFIGURATION 0x71_V4-COMMAND_CLASS_NOTIFICATION_V4 0x72-COMMAND_CLASS_MANUFACTURER_SPECIFIC 0x73-COMMAND_CLASS_POWERLEVEL 0x7A-COMMAND_CLASS_FIRMWARE_UPDATE_MD 0x80-COMMAND_CLASS_BATTERY 0x84_V2-COMMAND_CLASS_WAKE_UP_V2 0x85-COMMAND_CLASS_ASSOCIATION 0x86-COMMAND_CLASS_VERSION 0x98-COMMAND_CLASS_SECURITY

Catman · February 23, 2019, 6:03pm

Cheers Rafale. If anyone can help…

I don’t think it’s the command class. There’s 3 other identical sensors attached to that fibaro. All working perfectly:

24 02/23/19 16:32:49.411 ZWaveNode::HandlePollUpdate node 35 device 115 class 0x31 command 0x5 m_iFrameID 464/26204720 data 0x1 0x44 0x0 0x0 0x5 0x3f (#D###?) <0x77172520>
24 02/23/19 16:32:49.412 ZWaveNode::HandlePollUpdate_SensorMultiLevel_MeterReport 0x31 node 35 device 115 child 0/0 cat 17 embed: 0 type 1 rate type 0 is 13.430000 was 13.500000 prec 2 sca 0 size 4 delta -1 previous -1.000000 len 6 <0x77172520>

So the class seems fine.

Perhaps worth noting that the failed senor has a stack of variables assigned to it. They are all empty apart from as shown (Capabilities was empty. I copied from 115 in the hope of making it work)

The one that seems most important is ConfiguredAssoc: RECONFIG

Any ideas?

rafale77 · February 23, 2019, 6:15pm

Three things I would suggest you try:

recover from a backup prior to the sensor failure without zwave recovery. This would be a corruption of the vera user-data.json. Not uncommon. Mostly due to a luup crash/reload at the wrong time.
reconfigure the device which may delete and regenerate child devices (it’s dumb I know). If you have automation on using these child devices, you can always renumber the child devices after it’s done. The cause for this would be corruption of the zwave dongle data.
If 1 and 2 fail, power cycle the fibaro. This would be a device self corruption.

Catman · February 23, 2019, 9:29pm

Cheers.

All of those may well fix the issue, but I can’t really say they are acceptable solutions. If the system isn’t reliable, for what are we paying?

I’m not even sure how I can tell when the crash happened so I can deal with 1) The logging and rotation is so messy.
I’ve just gunzipped my oldest log from 20th Feb and the issue is there, so now I have no idea when the issue started

C

Catman · February 23, 2019, 9:36pm

Restored my earliest backup (cos I’ve not changed anything this week) and it looks like things are working

06 02/23/19 21:34:35.217 Device_Variable::m_szValue_set device: 116 service: urn:upnp-org:serviceId:TemperatureSensor1 variable: CurrentTemperature was: 8.12 now: 10.75 #hooks: 0 upnp: 0 skip: 0 v:0xc7cdf8/NONE duplicate:0 <0x7739c520>

(thanks)

Time to exroot?

C

rafale77 · February 23, 2019, 9:40pm

Could be… Looks like it was problem 1… You got your user data corrupted. Either you have a failing flash which means that your vera is dying, in which case extroot is the only way out before you get some other problems, or you just have some luup crash/reload to address.

Catman · February 23, 2019, 9:42pm

Hmmm

I think an extroot is probably cheaper than a new Vera

Mor kudos, chap!

C

Robohome · October 19, 2019, 3:34pm

Hi, I agree with the comment. I have the same problem. Once per month one of my sensor gets in stuck. When I check it, the reason is that “variables” → ConfiguredAssoc RECONFIG. It’s a strange because the same second device has absolutely another configuration and doesn’t have such field at all. Usually I recovery my system from backup, but after one month already another sensor gets in stuck. I noticed that usually it happens more often with sensors which send temperature (or consumption) data more frequently. If I reduce a frequincy data exchange then they don’t get in stuck anymore. I think that it is a problem with VERA. Please see below two pictures, the first (#149) is OK, the second is the same sensor (#150) but is in stuck.