stas-demydiuk / domoticz-zigbee2mqtt-plugin

zigbee2mqtt plugin for domoticz
MIT License
136 stars 98 forks source link

Power_outage_memory is not functioning properly #679

Closed SargonofAssyria closed 3 years ago

SargonofAssyria commented 3 years ago

Domoticz 2021.1 build 13360 Zigbee2MQTT version 1.20.0-dev commit: cee9eb1e Coordinator type zStack3x0 Coordinator revision 20210708 Frontend version 0.5.18 Latest plugin from today.

I changed the power_outage_memory today on several https://www.zigbee2mqtt.io/devices/TS0121_plug.html#tuya-ts0121_plug devices. That also changed the kWh to 10, 20 or 30 Watts when then plug is OFF depending on the setting of the power_outage_memory Before I change the state of power_outage_memory it was "unknown" and at that time the power was 0 Watts when the plug was OFF. In the MQTT messages the wattage is still 0 Watt, so those messages are OK.

Is it possible to fix this soon? B.t.w. there are no devices with ID of *_pwrmem on these plugs. Or is there a way to undo the setting?

SargonofAssyria commented 3 years ago

Found out that on some devices like bulbs the function is On/Off On other devices like smart plugs the function is a selector switch with On/Off/Restore (last state) but the initial state is nill So that's probably why there is no device created. I hope that a solution can be found, because Koenkk and nurikk did find a solution. See: https://www.zigbee2mqtt.io/devices/TS0121_plug.html#tuya-ts0121_plug

SargonofAssyria commented 3 years ago

I have some debug logging of that device switching on and off again. What happens is that the values get overwritten by the power_outage_memory value every time. 2021-08-20 13:56:35.721 (zigbee2mqtt - Wasdroger (Power)) Updating device from 1:'20' to have values 0:'0;14720'. 2021-08-20 13:56:35.727 (zigbee2mqtt - Wasdroger (state)) Updating device from 1:'On' to have values 0:'Off'. 2021-08-20 13:56:35.734 (zigbee2mqtt - Wasdroger (Power)) Updating device from 0:'0;14720' to have values 1:'20'. It looks like the plugin cannot distingue between 'power' and 'power_outage_memory' Both start with power. I can't solve it (lack of python knowledge), but it looks easy solvable. Wasmachine.log

heggink commented 3 years ago

I had a quick look to see whether I could understand why it is hapening but didn't manage to find the problem.

one thing you could try is to 'revert' the power_outage_memory change and see whether that gives you back the normal working. Edit adapter.py, search for power_outage_memory (line 179) and comment out the 2 lines below (add a # as first character on that line) leaving only the return statement. Restart the plugin and see whether that makes a difference. If not then the issue is indeed in a different area than the p_o_m handling.

SargonofAssyria commented 3 years ago

The problem is the fact that there are 3 kind of p_o_m devices

  1. https://www.zigbee2mqtt.io/devices/ZNLDP12LM.html#xiaomi-znldp12lm which has false/true
  2. https://www.zigbee2mqtt.io/devices/TS0121_plug.html#tuya-ts0121_plug which has on/off/restore
  3. https://www.zigbee2mqtt.io/devices/LED1903C5_LED1835C6.html#ikea-led1903c5%252Fled1835c6 which has off/previous/on The first kind of devices have there _pwrmem devices created as false/true as a light/switch with on/off The second kind has nothing created as _pwrmem devices, and those are creating problems as described. The third kind has _power selector devices created, that does not seem right??? But seems to behave normal. In mqtt message it has 'power_on_behaviour' So that is proberly where the _power devices are coming from. So commenting out the first type of binary devices does not solve the problem.

As long as the p_o_m device of type 2 has the value of null everything goes fine, but when I change the value in the GUI of zigbee2mqtt to 1 of the 3 possibilities then it goes wrong, then the value of the selector switch eg. 10/20/30 is going to be send to the _power device. I think the mix up comes from selector switch having _power deviated from 'power_on_behaviour' and/or 'power_outage_memory'

heggink commented 3 years ago

True but I don't get the point of replicating p_o_b functionality in zigbee2mqtt. It's a static parameter that can be easily set from the zigbee2mqtt interface. That's where my expectation was that manually reverting this change would resolve that dependency. In the zwavejs2mqtt plugin, we made the decision to only replicate state functionality and leave the rest in the zwavejs2mqtt web interface (so no inclusion in domoticz but in the web interface). Much less maintenance and issues.

SargonofAssyria commented 3 years ago

As I look at the code: by commenting out those 2 lines in the " def add_binary_device(self, feature):" you will prevent the devices from my example first type being created. But the problem is not with those devices, it is with the second type of devices, which are of type enum. B.t.w. It is not less maintenance, you still have to maintain it, but on an other place, and that might be confusing.

SargonofAssyria commented 3 years ago

Mistery solved, solution present, final solution (in source) not yet. In 'adaptor.py' there is a line for the selector definition. self._add_selector_device(item['name'][0: 5], item) that wants to create a device from "power_outagememory" -> power but that device already exists from power (kWh) it self. So I changed the 5 in 6 so it wants to create power (with extra underscore) from "power_outage_memory" and that went fine. There is a side-effect that all previous created devices with 'name' of more then 5 characters are new created with 6 char. So _effec -> _effect, _actio -> _action and _syste -> _system. Old devices have to de deleted. Who will change that with a commit?

heggink commented 3 years ago

why limit it to 6 instead of using the full label (power_outage_memory)? Any reason why self._add_selector_device(item['name'], item) would not work?

SargonofAssyria commented 3 years ago

Otherwise the ID can get very long and does not display well in the Domoticz GUI.

heggink commented 3 years ago

Yeah maybe but that has then led to this issue. Even choosing 6 characters is not very future proof in case something is changed zigbee2mqtt. Personally, I would not want all of these in the plugin anyway as I'd rather set them from the z2m webpage and forget. Saves maintenance going forward. But that's me.

stas-demydiuk commented 3 years ago

That's because DeviceID in Domoticz has the type Varchar(25), so it can't be longer than 25 characters

heggink commented 3 years ago

@stas-demydiuk That can't be: using our (moroen and myself) zwavejs2mqtt plugin, I already have many devices that have an id of 36 characters (example: "/161/113/0/Access_Control/Door_state").

SargonofAssyria commented 3 years ago

How is that possible, or are you using "Name"? 24 08 2021_16 48 42_REC Found it on the 'all knowing' Internet. _Note that numeric arguments in parentheses that following the type name (ex: "VARCHAR(255)") are ignored by SQLite - SQLite does not impose any length restrictions (other than the large global SQLITE_MAXLENGTH limit) on the length of strings, BLOBs or numeric values.

stas-demydiuk commented 3 years ago

@SargonofAssyria, back to your original issue, hopefully the latest plugin version that I've just pushed should handle that properly, so I wonder if you could upgrade and check.

SargonofAssyria commented 3 years ago

My Domoticz log file is, after a clean install on my test system, filled with

2021-09-04 14:11:50.636 Error: zigbee2mqtt: (zigbee2mqtt) 'onMessage' failed 'AttributeError':''NoneType' object has no attribute 'Name''.
2021-09-04 14:11:50.636 Error: zigbee2mqtt: (zigbee2mqtt) Exception traceback:
2021-09-04 14:11:50.636 Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 301 in '/opt/domoticz/userdata/plugins/zigbee2mqtt/plugin.py', function onMessage
2021-09-04 14:11:50.636 Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 135 in '/opt/domoticz/userdata/plugins/zigbee2mqtt/plugin.py', function onMessage
2021-09-04 14:11:50.636 Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 167 in '/opt/domoticz/userdata/plugins/zigbee2mqtt/mqtt.py', function onMessage
2021-09-04 14:11:50.636 Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 215 in '/opt/domoticz/userdata/plugins/zigbee2mqtt/plugin.py', function onMQTTPublish
2021-09-04 14:11:50.636 Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 61 in '/opt/domoticz/userdata/plugins/zigbee2mqtt/devices_manager.py', function handle_mqtt_message
2021-09-04 14:11:50.636 Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 64 in '/opt/domoticz/userdata/plugins/zigbee2mqtt/adapters/base_adapter.py', function handle_mqtt_message

And No device are created.

stas-demydiuk commented 3 years ago

Are there any logs prior to that to understand what is causing the issue?

SargonofAssyria commented 3 years ago

No that was normal, this is the log from the start of zigbee 2021-09-04 14:10:59.786 Status: zigbee2mqtt: (zigbee2mqtt) Entering work loop. 2021-09-04 14:10:59.786 zigbee2mqtt hardware started. 2021-09-04 14:10:59.787 Status: zigbee2mqtt: (zigbee2mqtt) Started. 2021-09-04 14:11:00.234 Status: zigbee2mqtt: (zigbee2mqtt) Initialized version 3.1.0-beta 2021-09-04 14:11:00.236 zigbee2mqtt: (zigbee2mqtt) Installing plugin custom page... 2021-09-04 14:11:00.257 zigbee2mqtt: (zigbee2mqtt) Installing plugin custom page completed. 2021-09-04 14:11:00.308 zigbee2mqtt: (zigbee2mqtt) Connected to MQTT Server: 192.168.2.239:1883 2021-09-04 14:11:00.411 zigbee2mqtt: (zigbee2mqtt) Zigbee2mqtt bridge is online 2021-09-04 14:11:00.419 zigbee2mqtt: (zigbee2mqtt) Received available devices list from bridge 2021-09-04 14:11:00.718 Error: zigbee2mqtt: (zigbee2mqtt) Hobbykamer: can not process numeric item "local_temperature_calibration" 2021-09-04 14:11:01.659 zigbee2mqtt: (zigbee2mqtt) Joining new devices is disabled on the zigbee bridge 2021-09-04 14:11:01.686 Error: zigbee2mqtt: (zigbee2mqtt) 'onMessage' failed 'AttributeError':''NoneType' object has no attribute 'nValue''. 2021-09-04 14:11:01.686 Error: zigbee2mqtt: (zigbee2mqtt) Exception traceback: 2021-09-04 14:11:01.686 Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 301 in '/opt/domoticz/userdata/plugins/zigbee2mqtt/plugin.py', function onMessage

My exception list is .*_power_;.*_effect;.*_pwrmem;.*_volt;.*_ampere;.*_thb;.*_lowbtr

stas-demydiuk commented 3 years ago

Could you please upgrade and check again

SargonofAssyria commented 3 years ago

Pulled again, emptied the exception list, now NO errors. But how do I fill the exception list, it looks like the unit number is now the type???

stas-demydiuk commented 3 years ago

You need to use zigbee feature name now instead of alias, so for example *_lowbtr will be now *_battery_low

SargonofAssyria commented 3 years ago

Checked it with .*_effect and it worked. Tnx. I keep testing before I put it into production.

SargonofAssyria commented 3 years ago
  1. There is a small problem with excluding 'illuminance' and/or 'illuminance_lux' Is there a solution?
  2. I have a lot of devices, a lot of them have to be created again. Is there a logic in the current setup of ID and Unit? I might be be better of to create a few sql command to rename the ID's and Units from old to new and save a lot of work and keep the history.
stas-demydiuk commented 3 years ago
  1. What's the issue with illuminance?
  2. DeviceID now equals to device zigbee IEEE address, unit is just first available unit (from 1 to 255) for that device_id. Once the device is created, the plugin adds appropriate alias to configuration. What's the issue with your devices, all previously created devices should continue to work just fine?
SargonofAssyria commented 3 years ago

illuminance issue is I cannot exclude one or the other. When I put in 'illuminance' both are excluded.

As I saw that ID is changed I thought that new device will be created. Could/Will not test it in production yet.

stas-demydiuk commented 3 years ago

As each item in a blacklist is a regex I guess you could try smth like *_illuminance$

stas-demydiuk commented 3 years ago

@SargonofAssyria, do you still have the original issue or ticket could be closed?

SargonofAssyria commented 3 years ago

In my test environment I don't have this issue any more. :)