full devices reset

[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