forum

I've seen this as well when POSTing to the Json API. From what I understand, it is the result of the end device reporting a value before it is still executing the command to dim up/down. Subsequent calls to read the value in question returns the correct value.

Not that I know of.

This looks much like my issue here: http://en.z-wave.me/content/retrieving-updates

If you invalidate the data by calling ZWaveAPI/Run/devices[?].instances[?].commandClasses[?].Get() do then get status update?

Does the default installation of RaZberry activate log rotation of the /var/log/z-wave-server.log file?

Good news

<r>Hello,<br/> <br/> The documentation (<URL url="http://razberry.z-wave.me/docs/zway.pdf">http://razberry.z-wave.me/docs/zway.pdf</URL> section 7.4) states:<br/> <br/> "The tree have same structure as the backend tree (Figure 8) with one additional root element<br/> "updateTime" which contains the ...

<t>Some additional information:<br/> <br/> It seems the above problem is related to command class 50 (CC 49 is working as expected). The same problem can be seen in the RaZberry UI; "Power"-sensors are updated on-the-fly, while "Electic"-sensors requires the "update" button to be pressed.<br/> <br/>...

I mailed Fibaro about this, pointing them to this thread. Unfortunately the answer I got was just this:Dear Sir, Could you remind your issue? -- Pozdrawiam, Regards, Marcin JanickiNot sure what he actually means? I mailed back and asked for clearification, but no response yet.

Well, Fibaro don't understand the problem according to their latest mail.

I've reproduced this with another RaZberry/Wallplug pair.

I'd appreciate if someone with indepth knowledge of the RaZberry comments on this.

Thanks.

Yes, I know I can trigger the update - but why is that required for this command class and not others? CC49 is updated without a call to Get(), why not CC50 too?