Fibaro FGD212 Real time energy usage (watts) always a step behind

Has anyone seen this? Lets say the light is off, 0 watts. Turn it on to 50% and it shows 20watts, turn it to 100% and it shows 40 watts. Then turn it back to 50% and it still shows 40 watts still, take it back to OFF and it shows 20 watts

It always appears as if the real time usage is one step behind the actual usage? Ie the measurement now, is from the previous setting

Has anyone sen this or worked out away to fix it? Ive tried every setting available.

Even when its off, its showing the previous wattage. If I then send another OFF Command when its off, it shows 0 correctly.

Cheers and thanks

No.
sensor_power1 channel is working as expected.

Hi sihui, so what is meter_watts for?

Both show the issue for me

17% brightness, showing 84 watts.


15:21:15.885 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'LivingRoomDim1' received command 17
15:21:15.887 [INFO ] [arthome.event.ItemStatePredictedEvent] - LivingRoomDim1 predicted to become 17
15:21:15.887 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingRoomDim1 changed from 100 to 17
15:21:17.438 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingRoomNum1 changed from 4.7 to 84.6

So i change the dim value to 12% and it drops from 84 watts (17% dim) to 17 watts (12% dim)

15:22:02.125 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'LivingRoomDim1' received command 12
15:22:02.125 [INFO ] [arthome.event.ItemStatePredictedEvent] - LivingRoomDim1 predicted to become 12
15:22:02.126 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingRoomDim1 changed from 17 to 12
15:22:03.678 [INFO ] [home.event.GroupItemStateChangedEvent] - gAllLightsUsage changed from 117.48 to 50.08 through LivingRoomNum1
15:22:03.679 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingRoomNum1 changed from 84.6 to 17.2

Clearly there is something broken.

I never looked in the manual to find out :sunglasses:

Then use the sensor_multilevel command class which is working fine.
I remember reading something about comparison watts vs power, you will be able to find it through the forum search.
Actually it’s the same, just different command classes.
So I would recommend to use the command class which is working better than the other …

There is no channel sensor_multilevel.

The channel meter_watts or sensor_power exhibit the same behavior.

sensor_multilevel command class, not channel. Inside the sensor_multilevel command class there is a channel sensor_power (or sensor_power1 for the other endpoint)

I just tested it, it is working fine.

On what OH2 version, Binding version, Firmware of the Fibaro version?

3.3

It is one of my oldest devices and has worked from 2.0 to my current 2.5 snapshot.

Fair enough. It should be as easy as just creating the channel and setting dim to 100% and 0% but this does not generate the right figures, no matter what I do. Deleted the channels, the items…

I assume this item definition is OK, where by I use the Switch item to do on/off and the dimmer type for dimming


/*ZWave Dimmer 2 Living Room Lights*/
Switch LivingRoomSw1  "Living Room"                                    (gLights_Random,gAllLights,gInsideLights)                  { channel="zwave:device:4296a94a:node2:switch_dimmer1" }
Dimmer LivingRoomDim1 "Living Room [%d %%]"                            (gAllDimmers)                             [ "Lighting" ]   { channel="zwave:device:4296a94a:node2:switch_dimmer1" }
Number LivingRoomNum1 "Living Room - Current Consumption [%.1f W]"     (gAllLightsUsage,gEnergyRealTime)                          { channel="zwave:device:4296a94a:node2:meter_watts1" }
Number LivingRoomNum2 "Living Room - Usage [%.1f kW]"                  (gPowerUsage)                                              { channel="zwave:device:4296a94a:node2:meter_kwh1" }

This sounds familiar, something like the status returned by the device in response to a command is the status before applying the command i.e. too quick.

I cannot now find the story about this; I think it may involve setting the association in the dimmer.

hi rossko57, that’s certainly what it does. The associations are correct and with @chris new binding this is apparently a non issue now (Associations)

As I said before, with sensor_power1 it is working fine:

Number FibFGD212_1_Pwr1 { channel="zwave:device:uzb:node37:sensor_power1" }
Number FibFGD212_1_Kwh1 { channel="zwave:device:uzb:node37:meter_kwh1" }

Are you talking about the command poll period?

Yup, that’s what tickled my memory. So it seems to be a per-device setting you can access via Habmin. Not clear if/how it affects multi channels on one device.

It is quite reasonable that onboard power calculations would lag behind device dimmer setting, so a timing issue looks probable.

Ill try changing the command poll period. Thanks

Never really understood why you would want instantaneous watts but it works fine. No need to use the command poll period. I have that disabled.

If it is not working have you tried parameter 50 set to a lowish value.

0 disables and that is best unless you need it.

Para 50 is set to 10, which i believe is default.

So it only sends a message if the change in W is > 10% of the current load. if you make small changes you will not see a lot. As long as you see the big changes then it is working. The dimming % will not have a direct correlation to the W so it is not a 10% change in dimming level.

If you are desperate to see blow by blow changes then you could set it to a lower value but unless you are using the change in a scene why waste the network bandwidth?

I have used the W channel for only one thing and have not set that automation up on OpenHAB yet. That was to turn on my kitchen extractor when the electric oven is turned on.

The only other automation I have heard it used for that made sense to me was someone that used it to monitor their TV turning on and off and used a roller shutter control to power the lifter.

If you have something like that then leave parameter 50 to as small % as needed to make the automation work and use the value. If not then set parameter 50 to 0 and turn the report off so it does not waste your Zwave bandwidth.

Would not recommend the poll after as that will doubly waste your network bandwidth.

1 Like

As I understood the OP’s issue, setting the dimmer to say 0% could result in power reading of nnW in his openHAB Item. Until the next change.

Not everyone is interested in power consumption, but some people use it to predict costs or manage solar storage or blah.
Such a false reading overnight would clearly mess that kind of thing up.

It’s reasonable to expect this feature to work.

2 Likes