Zwave: Node initialising: STATIC_VALUES

Setup, Configuration and Use Runtime
, ,
4

Also just noticed all of this, which looks a bit odd:

2016-10-05 14:24:12.162 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 33: Application Command Request (ALIVE:STATIC_VALUES)
2016-10-05 14:24:12.162 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 33: Incoming command class METER
2016-10-05 14:24:12.162 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 33: Received METER command V3
2016-10-05 14:24:12.162 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 33: Meter: Type=Electric(1), Scale=kWh(0), Value=12.08
2016-10-05 14:24:12.162 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent
2016-10-05 14:24:12.162 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Got an event from Z-Wave network: ZWaveMeterValueEvent
2016-10-05 14:24:12.162 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Got a value event from Z-Wave network, endpoint = 0, command class = METER, value = 12.08
2016-10-05 14:24:12.162 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Updating channel state zwave:device:c5ef376d:node33:meter_kwh to 12.08 [DecimalType]
2016-10-05 14:24:12.162 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_W <> E_KWh
2016-10-05 14:24:32.820 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 33: Stage STATIC_VALUES. Initialisation retry timer triggered. Increased to 1800000
2016-10-05 14:24:32.820 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 33: Node advancer - STATIC_VALUES: queue length(0), free to send(false)
2016-10-05 14:24:32.820 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 33: Initialisation retry timer started 1800000
2016-10-05 14:24:32.820 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 33: Node advancer: Retries exceeded at STATIC_VALUES
2016-10-05 14:24:32.820 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 33: Retry timout: Can't advance

The “Initialisation retry time” I have no clue about, but how can the scale be wrong?

Also, I see :
2016-10-05 14:24:12.162 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 32: Transaction not completed: node address inconsistent. lastSent=32, incoming=255

Is this saying that node 32 is pretending to be node 255? I removed NODE 32 from the controller, so I’ve no idea what is going on here!

5

I’m not sure what you are thinking looks odd? To me I think it’s ok. I guess you might be looking at the “Not the right scale” message (??) but this is ok - I should really remove this debug message. Since there are 2 meter channels, the system is checking both configurations, and one is updating the channel, and the next one it shows is not the right scale (correctly).

This is ok as well. This debug message is related to transaction management. It basically means that it received a message from the controller (node 255) but the last message sent was to node 32 and these two messages are not consistent, so it doesn’t complete a transaction. This happens normally when devices send unsolicited messages (such as meter updates, door notifications etc).

All good there :slight_smile: .

I’ll take a look at your log later tonight…

6

Okay - thanks a lot Chris!

7

Hi @chris, just wondering if you’d had time to have a look? (Apologies for pestering)

8

No problem - I’ve been travelling a lot for work over the past few weeks, and it’s easy to loose track of things with the forum.

I’ll take a look now.

9

Mainly for my future reference, the failure is because the device isn’t responding to the ASSOCIATION_GROUP_INFO_GET request.

Pasted image936×450 94.2 KB

From my reading of the spec, this is non-compliant behaviour (which is surprising for Fibaro) but I’m trying to double check this. It might be worth resetting this device to see if that changes anything. If this turns out to be a bug in the device I’ll look at adding something to the binding to work around this.

10

Ok thanks! I won’t be able to physically reset the device for a week or so, but I have two devices behaving identically so unfortunately I don’t think it’s just a glitch.

11

Ok - that’s good to know, thanks. I’ve enquired about this with the zwave people, so let’s see what they have to say as in my reading of their spec, the device is non-compliant even though they have checked it, and it’s approved ;).

12

I have noticed same issue for FGD212 dimmer (Firmware 3.2) .Node initialising: STATIC_VALUES
Also I have one FGD212 for firmware 3.3. and it doesn’t have this issue.

13

That’s really interesting… I suspect that this is a bug in the 3.2 firmware - I’m pretty sure it’s non compliant to the standard…

14

I have done little more testing and added 2 more new FGD212 Things (firmware 3.3) on OH2. One installed without errors on habmin2 and another give same STATIC VALUES ERROR than FGD212 firmware 3.2. Very strange.

I have used them with OH2 MIOS binding from Vera and they work very well. Now I have tested with ZME_UZB1 zwave controller. Maybe next I will try hard reset to problem Things.

[ERROR] [alization.ZwaveNodeInitStageAdvanced] - NODE 7: Node advancer: Retries exceeded at STATIC_VALUES
[ERROR] …Timeout while sending message. Requeueing…
[ERROR] Got an error while sending data. Resending message…

Do you have any idea?

15

Only what I’ve already said above - I’ve no further information for any other ideas :wink:

16

Hiya @chris, have you heard back from the zwave folk yet?

Even if you do though and they agree it’s non-compliant, what next? I don’t think there’s any way to update the firmware in this device, so is it possible to work around this some other way?

17

Yes, but nothing especially useful - they said -:

If a node support a command class, it must answer a get.

So I read this as the device is non-compliant :frowning: .

18

Blast. :frowning:

Edit: @chris any possibility of a work around then? As mentioned I don’t think I can upgrade the firmware, and apparently this device was working okay in OH1.8. A ‘compatibility’ mode or something?

19

The reason it worked in 1.8 is because 1.8 doesn’t support this command class. I hope to have an update at some stage that will be more tolerant to devices not responding like this (unfortunately, it’s not that uncommon - I’m not sure what that says about the ZWave certification program!).

The other option is we can remove this command class - ie add something to the database that tells the binding not to use it - this is the easiest/quickest at the moment, and given this command class is just an ‘information’ class, it won’t change anything.

20

I’ve updated the database to remove this class. Please try with the updated version which should be finished building shortly…

21

Hmm. In PaperUI I uninstalled and re-installed the binding, then restarted openhab. Is this sufficient?

I see:
2016-10-12 10:48:21.092 [DEBUG] [inding.zwave.internal.ZWaveActivator] - Z-Wave binding started. Version 2.0.0.201610011937

The reason I ask is both devices are still flagged “Node initialising: STATIC_VALUES” in Habmin (and I don’t see the xml files).

Edit: Ah, is that a timestamp, i.e. 1st of Oct? I guess I didn’t get the latest version if so… :frowning:

22

There is a problem with the builds at the moment due to an OH1 issue, so the last build is 3 or 4 days ago.

23

Hmm. I’m obviously reading the jenkins output wrongly then … if I look here:
https://openhab.ci.cloudbees.com/job/openHAB-Distribution/

I see: “Last successful build (#529), 1 hr 26 min ago”

So should my update procedure have worked then (i.e. use paperUI to uninstall/reinstall the binding)?

Thanks (and apologies for all the questions!)