full devices reset

[PerH]

I have an odd issue which seems to be only for Fibaro wall plugs. They come in to Z-Way with two "electric meter" entrys, one "Power" meter and a couple of alarm entrys. In addition to the switch that is.

One of the "electric meters" is KWh and the other one is seemingly Watts, but it stays at 0/-1w. The "Power" meter shows the Watts used right now.

When these come into openluup, the wrong electric meter is selected for displaying the Watts, is there any way to manipulate which one openLuup uses? I see that the sub channel for power also is transferred, but it isn't in the data Veraflux is transmitting to my influxdb..

Haven't used the watts reading for anything before now, now i want to estimate when my dryer is done based on power usage.

[PerH]

This is how one of them comes into openLuup, and I see that the value for device 25111 comes in to a variable on the 20710, but it isn't updated in the child device?

[akbooer]

Can you show me the complete variable list for the actual parent device? This should have all the values received from ZWay.

[PerH]

Her you go:

49-4 is the correct number for the Power child 25111, here from z-way:

(the dryer shifted modes between screenshots, 345.1 and 131.89 is the same entity)

[akbooer]

Hmm, I see a bit of a conflict here. Command class 50 is for metering, but 49 is a multi-level sensor. It’s going to be hard to find a rule to deal with that automatically. Let me see if there’s a fix to achieve this manually… or, perhaps, @rafale77 has a suggestion?

[PerH]

Strange. Looked at my other devices, and it seems to be Fibaro Dimmer 2 and Fibaro wall plug out of my devices that use CC 49. Double Switch has meters on 50..
Also strange that a meter is made for these devices at command class 50, but it's not reporting on them?
This is a fibaro issue, i guess? Z-Way is just reporting the command classes used by the device?

[akbooer]

The ZWay plugin uses the high-level interface to the ZWay firmware. As such, it only has access to those things which that API provides. It seems somewhat random sometimes. Through this interface we are seeing the sensor in question, but it's an issue to do with how we represent these as child devices. However, the 'raw' variable in the parent device zway_71-0-49-4 is available for you to read, but you can't set a variable watch on it. You'd have to poll it with a timed scene, or such like.

I will look further into adding this to the child device, but, as mentioned, there may be a conflict with other reported power variables. We'll see.

Edit:

Yes, there is potential conflict. Just checked the source code and find this comment:

--  2020.03.05  "Watts" conflicts with meter "50-2" if both present

I may, in general, be able to code around this in the event that there is no reported command class 50-2, but for this device there IS, so that's a problem.

[PerH]

Yep, it reports a semmingly bogus value (0.5/-1watts). mabye one could throw in a selection variable where I can manually select which one to use as power reading for the main device?

[PerH]

I'll ask @PoltoS about this over at the z-way forum as well, as it isn't really an openLuup problem..

[ArcherS]

@perh I have one Fibaro Plug also for the drip coffee maker.

Mine does seem to update the power (W) in Zway and also in OpenLuup, however in AltUI only the energy (kWh) is shown, the presented Watt is always zero.
In OpenLuup the "W" variable seems to update and the "Watts" is always zero.

In general I think that Fibaro devices seem to have problems, I suspect that they do not fully follow the zwave standard or something. My aim is not to buy any more Fibaro devices.

[PerH]

Same behaviour as here then.
I have only good experience with the fibaro units except for this issue, so i hope Fibaro or Z-way finds a solution/explanation. (I've asked them both)

[PerH]

https://forum.z-wave.me/viewtopic.php?f=3419&t=34427

PoltoS states that this is the new way of doing things, as the meter value is an accumulative value? I guess this is something to count in for other new devices as well then?

[akbooer]

@PerH

Thanks for that, especially the pointer to other thread.

Yes, meters should accumulate, so I take the point. I think that perhaps the best course of action would be to prioritise the 49-4 sensor over the meter, if both are present. This certainly resolves the currently documented conflict.

Whether this causes some legacy issues, I couldn't say, but I'll make that change and see if there's any feedback.

I'll get to this is a few days, since I'm still awaiting a Shelly dimmer device so that I can add that to supported ones in the Shelly bridge.

Thanks again,

AK