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
Indeed. It’s not so much the consumption, but the fact its showing something when its off. That’s my real issue.
I do not get that issue so I am not sure it is inherent in openHAB but it could be to do with the Fibaro device and type of load connected. I tested a few of mine and none show this issue.
There is that strange parameter 59 that I could not get Fibaro to explain when to use to me when I was testing a preprod one of these for them. I have never used it.
Not sure about the power reported on this channel as a way to work out energy need or usage. It just would not be accurate to take samples on instantaneous W when you have a cumulative kWh channel that is always going to be more accurate. If people find it useful I am not going to argue but deltas of the energy would be my way to work out demand.
dastrix80 do you doubt the kWh reading? Understand that seeing a W figure is disconcerting but is it a material issue.
If it is, could you start by getting the logs. If it is an OpenHAB issue then it must be ignoring a report from the device. If the device is not sending a report then it is a Fibaro issue and you can add that to a long list of firmware issues in devices. Fibaro not necessarily being the worst offenders but these dimmers have had their issues with flickering in certain regions of the world and other unwanted behaviour. Could be that with the type of load you have connected these behave differently to how mine do.
The issue is that a device, holds onto its Watts channel data and does not return to 0 .
When I turn the light on, it shows 20Watts instantly. When I turn it off the channel still shows the value for hours . The other devices do it just fine.
The kwh reading is not an issue, its the instantaneous watt reading. This isn’t a material issue if someone is using this to judge total load on an off the grid premises.
Yep, my Fibaro dimmers flicker no matter what I do under 30-40% load. Aeotec ones do too.
The load is all LED globes.
All lights off, now showing 2.9 Watts
07:48:35.107 [INFO ] [arthome.event.ItemStatePredictedEvent] - LivingRoomSw1 predicted to become OFF
07:48:35.108 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingRoomSw1 changed from ON to OFF
07:48:35.109 [INFO ] [home.event.GroupItemStateChangedEvent] - gInsideLights changed from ON to OFF through LivingRoomSw1
07:48:35.110 [INFO ] [home.event.GroupItemStateChangedEvent] - gAllLights changed from ON to OFF through LivingRoomSw1
07:48:35.228 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingRoomDim1 changed from 5 to 0
07:48:35.229 [INFO ] [home.event.GroupItemStateChangedEvent] - gAllDimmers changed from UNDEF to 0 through LivingRoomDim1
07:48:38.349 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingRoomNum1 changed from 1.4 to 2.9
07:48:38.350 [INFO ] [home.event.GroupItemStateChangedEvent] - gAllLightsUsage changed from 1.4 to 2.9 through LivingRoomNum1
openhab> smarthome:status LivingRoomDim1
0
openhab> smarthome:status LivingRoomNum1
2.9
openhab>
It’s always the same device, the Fibaro.
How did you get on with command poll period?
Same issue, the light is off and its showing 2.9Watts on the channel. Always the same device, LivingRoomNum1
Even changing the power reports to 1, doesnt do it. Light off, showing 13Watts. If I send an off command again, after its already off, it updates. Surely this is a bug?
I am running firmware 3.5 no bypass 3 wire with LED load and no issues like that and have no flickering.
I am sure your issue is with Fibaro and install not openHAB. Have you asked on the Fibaro forum to see if anyone has had the issue and solved it?
Im still having this issue, now with Aeotec devices. The device is on, the association group set yet the usage on the Wattage channel is showing 0.
@chris I assume you need a debug log to see whats going on when the light is switched on/off? This must be a software issue.
What is the command poll period set to on this one?