Allow energy entity from switch

[alexeiw123]

The problem

Using smart switch PC191HA, have set up and created energy entity using Riemann sum integral method. Issue is that polling frequency is very low and this likely to introduce inaccuracies.

From Tuya developer account, one of the available "dp_id" is the device's own register of energy (see below).
Having a field in entity set up to declare energy would be both easier and likely more accurate. I assume other tuya smart switches have the same.

      {
        "code": "add_ele",
        "dp_id": 17,
        "type": "Integer",
        "values": "{\"unit\":\"kW·h\",\"min\":0,\"max\":50000,\"scale\":3,\"step\":100}"
      },

-->

Environment

• Localtuya version: 4.0.1

[jasonwragg]

The problem with add_ele is that it resets to 0 every time it connects to Tuya and uploads the usage data you would need to block the device from connecting to Tuya to use it.

[alexeiw123]

Oh, well now it makes sense that it's not used. That's pretty inconvenient!

[biffel]

Mine (an Arlec 'Grid Connect' switch from Bunnings Australia) doesn't seem to work the way jasonwragg describes.

As best I can determine, dp_id 17 "add_ele" consistently seems to hold the most recent value that was sent to the Tuya cloud (which it does every half an hour).

Unfortunately, asking the device to 'update_dps' with dp_id 17 never results in it returning an updated value - only asking for 'status' (i.e. of all dp_ids) seems to give a current value. And therefore it looks like it contains useful data when adding a device - the figure shown matches the reported 'Add Electricity' figure in the Tuya cloud history. But it is never updated when asked using update_dps.

In theory, at least, if I could retrieve the value of dp_id 17 every half hour (using 'status', perhaps?), I could sum the results to determine energy usage with reduced risk of error. (My use case is thermostat-controlled espresso machine, which when idle has a short on cycle and a long off cycle.)

[nvx]

I'm seeing the same behaviour as @biffel describes using a Mirabella Genio Smart Plug with energy monitoring (the newer ones with the power button on the same face as the plug itself, the older ones with the power button on the top of the plug do not appear to have dp_id 17 at all, only 18-20).

I thought maybe setting a scan interval would force it to refresh, but no dice. Would be nice to have proper energy monitoring of tuya plugs.

[biffel]

I have a box of four from Bunnings, purchased about two months ago - and it looks like two of the units in the box produce dp_id 17 (the first two I configured), and two don't (which I configured later). I can't explain this, or whether there is something I have done accidentally to reach this outcome. All four have the power button on top.

Regardless, I agree with the point @nvx makes: 'Would be nice to have proper energy monitoring of tuya plugs.'

[henkkakay]

I have same issue that dp_id 17 is not decoded.

Turned on debug level logging, removed all localtuya devices from the integration, and try to re-establish connection to one of them. This is the result:

2022-10-24 21:39:52.983 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf1...XXX] Sending command status (device type: type_0a)
2022-10-24 21:39:52.984 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf1...XXX] Send payload: b'{"gwId":"bf1b8e83685c061aXXXXXX","devId":"bf1b8e83685c061aXXXXXX"}'
2022-10-24 21:39:52.994 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf1...XXX] Waiting for sequence number 0
2022-10-24 21:39:53.093 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf1...XXX] Dispatching message TuyaMessage(seqno=0, cmd=10, retcode=0, payload=b'[\xaf8|\xd7\x1f\xe2\xf8\x07\xfd\t\x8a8\xed\x9d\xf1\xa6\x89\xd1a\xbb\x9a\x84\x98\x0b\xe1[\x9f\xa6g\x0e\xa3;\xb1\xc2\xca\x16\x05\x1fe\xe8CQ\xaa\xf3\x19\xc1\x99\n\xc3xB\xecf^\x84\xd9\xd5\xc6&\xb1%\x8d\x035\xad\xb0\x1dw.\x94%1&H\xXX\xXX\xXX\xXX`', crc=382990XXXX)
2022-10-24 21:39:53.096 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf1...XXX] Dispatching sequence number 0
2022-10-24 21:39:53.098 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf1...XXX] Decrypted payload: {"dps":{"1":true,"9":0,"18":285,"19":371,"20":2276,"26":0,"38":"on"}}
2022-10-24 21:39:53.098 DEBUG (MainThread) [custom_components.localtuya.config_flow] Detected DPS: {'1': True, '9': 0, '18': 285, '19': 371, '20': 2276, '26': 0, '38': 'on'}
2022-10-24 21:39:53.099 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf1...XXX] Closing connection
2022-10-24 21:39:53.101 DEBUG (MainThread) [custom_components.localtuya.config_flow] Total DPS: {'1': True, '9': 0, '18': 285, '19': 371, '20': 2276, '26': 0, '38': 'on'}
2022-10-24 21:39:53.107 DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf1...XXX] Connection lost: None

The messages are decoded correctly so the local key is ok, but DPS 17 is not on the decoded list.

When I compare what can be decoded (say - DPS=18) and what is not (DPS=17)

    {
       "code": "add_ele",
       "dp_id": 17,
       "type": "Integer",
       "values": "{\"unit\":\"kW·h\",\"min\":0,\"max\":50000,\"scale\":3,\"step\":100}"
     },
     {
       "code": "cur_current",
       "dp_id": 18,
       "type": "Integer",
       "values": "{\"unit\":\"mA\",\"min\":0,\"max\":30000,\"scale\":0,\"step\":1}"
     },

there is one (and only one) thing that stands out to me: that "kW·h" with that dot between "W" and "h" - I wonder if the current code cannot handle this character and so abandons dp_id = 17. I dont know what character that is but it is clearly not a "fullstop . ". The same dot exists in @alexeiw123 message above.

The units I have are also "Arlec White Grid Connect Smart Plug In Socket With Energy Meter" with model PC191HA, also bought from Bunnings.

Edit: I have isolated my ESP32/Tuya WiFi AP so devices on that network do not have access to cloud (thats one good reason to have LocalTuya) so the problem mentioned by @jasonwragg is (should?) not be relevant to me

[nvx]

ooh, I'm guessing that's a unicode character. Is something breaking when non-ascii characters are encountered perhaps?

[henkkakay]

spent some time looking at some of the code, based on my very limited knowledge it appears the segment like mentioned (obtained from Tuya's website) seems to only describe the DPD:

    {
       "code": "add_ele",
       "dp_id": 17,
       "type": "Integer",
       "values": "{\"unit\":\"kW·h\",\"min\":0,\"max\":50000,\"scale\":3,\"step\":100}"
     },

And so the "kW·h" has nothing to do with what the device sends out as regular updates. In all likeliness the actual update just contains something like the log above sample "18":285

what that means is: my suspicion above is probably wrong, and the device is in fact not sending out DPD=17 within its updates, and needs some sort of triggering for it to be sent.

[tbgoose]

I know this is sort of old / perhaps stale, but why not just move on and create your own energy consumption sensors using Reimann Sum Integration integration and then use the utility_meter integration to create daily/monthly values for energy use? I trust HA to do this better than Tuya anyway... I use a split config so if you don't then need to fix indentations. I also create separate power, current and voltage sensor entities for all my devices in LocalTuya as I like it this way. Can do this pulling attributes if you don't do it this way.

inside sensors.yaml

- platform: integration
  source: sensor.kitchen_fridge_socket_local_power
  name: kitchen_fridge_socket_consumption
  unit_prefix: k
  round: 2
  method: left

inside utility_meter.yaml

daily_kitchen_fridge_socket_local:
  source: sensor.kitchen_fridge_socket_consumption
  name: Daily Kitchen Fridge Socket
  cycle: daily
monthly_kitchen_fridge_socket_local:
  source: sensor.kitchen_fridge_socket_consumption
  name: Monthly Kitchen Fridge Socket
  cycle: monthly

[alexeiw123]

I trust HA to do this better than Tuya anyway

That is how I'm doing it, and it works 'ok'. The issue is that the some of these tuya smart plugs have pretty crude power update intervals.

My assumption is that the built in register for energy accumulation will be more accurate than an integration of a very coarse plot of power every few minutes.

[tbgoose]

When setting up any power monitoring device in Local Tuya, force 30s for the update interval. Can do this without having to set the whole device up again.

[alexeiw123]

oh wow - can't believe I haven't played with this. From documentation: "Setting the scan interval is optional, it is only needed if energy/power values are not updating frequently enough by default. Values less than 10 seconds may cause stability issues" Have you tried lower than 30s? I've got a pile of tuya energy monitors, I'll give this a shot.

…

On Thu, 8 Dec 2022 at 11:44, tbgoose ***@***.***> wrote: When setting up any power monitoring device in Local Tuya, force 30s for the update interval. Can do this without having to set the whole device up again. [image: Screenshot 2022-12-08 10 41 55] <https://user-images.githubusercontent.com/11631657/206328378-fd7442cc-b671-4c50-b178-a6c64073ab6c.png> — Reply to this email directly, view it on GitHub <#932 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASRURBLA7FNCQ76MUFZDU4DWMEVNXANCNFSM52RK6SRQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tbgoose]

Nope I just read the docs and picked the default. I think thats probably fine grained enough to get a pretty good idea. Although I guess you could argue that it might miss a whole kettle brewing if its only 2 cups... Maybe I should try reduce to 15s...

[alexeiw123]

I'll take a backup, start at 15 and work my way up. The other DPs aren't showing up when I edit the configuration so I'm mindful that something might break!

[tbgoose]

15s seems to work fine. Probably a worthwhile change as it effectively doubles the accuracy of the consumption values.

[alexeiw123]

so uh yep, that makes a huge difference...
My energy accuracy concerns will be largely addressed too.

[petermnz1]

When setting up any power monitoring device in Local Tuya, force 30s for the update interval. Can do this without having to set the whole device up again.

Thanks saved the day, such an easy fix. You can do it after intial setup too - localTuya / configure / edit device.
Cheers