Home Assistant : Q&A, Tips & Tricks, Your Configs

[McGuywer]

For everyone running Home Assistant, what would be the best device to install it on when I start with my setup?

I would say, start with a VM.
Play around, then go from there.
If you have a seperate PC available, something like Proxmox is nice, then you can run multiple things.

 

[McGuywer]

You need to track energy separately inside HA.

You can derive this from the power using a Riemann sum helper

It use to be there, I know other people have it as well.

 

[DrJohnZoidberg]

It use to be there, I know other people have it as well.

I have some Tuya devices that report it, it's never close to accurate though.

 

[acidrain]

For everyone running Home Assistant, what would be the best device to install it on when I start with my setup?

Any cheapie SFF pc. I have it running in VM on 2 cores and 4GB RAM.

Just don't use a Pi unless it has nvme storage.

 

[Veroland]

Which integration are you using?

Hi, LocalTuya

I used the tuya developer console to check which entities to map

 

[valiente]

Hi, LocalTuya

I used the tuya developer console to check which entities to map

Check out tuya-local - Similar integration but I have had a lot more success with it and moved over all my Tuya based integrations to this one.

 

[Mzezman]

For those so inclined - PiHole V6 is now public

Introducing Pi-hole v6 – Pi-hole

pi-hole.net

I'm going to wait a bit as i need to see how well it works with Unbound AND move from GravitySync to OrbitalSync

 

[TedLasso]

Ok, so I am befok

Had to replace my old garage door motor. I had a SONOFF SV (Tasmota) connected to it and had setup the GPO14 to be a sensor to let me know when door is open / close. It worked well and was reliable

The new centurion garage door motor works slightly differently in that nothing moves along the track (like my old one) . I had put the magnet switch on the moving bit and it worked well to tell me door was closed.

So now, I bought a wide gap magnetic switch and mounted it as it was the only way. Still the same SV and the same config. However, HA is now reporting the state in reverse order. When the magnets are together, it's open, and when they are not together, it's showing as closed. The regal person sold me a normally closed switch if I recall correctly. I already know that the switch is working in a different way to the old one.

This is my current HA config for the Sonoff SVs (they are the ones that started my HA journey)

Switch Config

    - name: "Garage Door"
      unique_id: 9b7b0191-22c6-40d3-b13d-83169773cb70
      icon: mdi:garage-variant
      state_topic: "stat/garagestate/POWER2"
      command_topic: "cmnd/SNOFF_GarageDoor/POWER"
      availability_topic: "tele/SNOFF_GarageDoor/LWT"
      qos: 1
      payload_on: "ON"
      payload_off: "OFF"
      payload_available: "Online"
      payload_not_available: "Offline"

Cover Config

mqtt:
  cover:
    - name: "GARAGE DOOR-1"
      unique_id: 3b1b5f70-6d87-40e9-a079-0e4a90e16252
      state_topic: "cmnd/garagestate/POWER2"
      command_topic: "cmnd/SNOFF_GarageDoor/POWER"
      availability_topic: "tele/SNOFF_GarageDoor/LWT"
      qos: 1
      payload_open: "ON"
      payload_close: "ON"
      payload_stop: "ON"
      payload_available: "Online"
      payload_not_available: "Offline"
      state_open: "OFF"
      state_closed: "ON"
      optimistic: false
      retain: false

I had thought just swapping the payload_on/payload close, i.e all ON become OFF and all OFF become ON, in the COVER config should reverse what HA is showing but it appears I am doing something wrong. As far as I know the Cover is what shows the state of the gate?

But it's been so long that I looked at HA (mines has been so very reliable and nothing needed adding or tweaking) that I lost what I had of my limited skills!

 

[TedLasso]

Ok, so I am befok

Had to replace my old garage door motor. I had a SONOFF SV (Tasmota) connected to it and had setup the GPO14 to be a sensor to let me know when door is open / close. It worked well and was reliable

The new centurion garage door motor works slightly differently in that nothing moves along the track (like my old one) . I had put the magnet switch on the moving bit and it worked well to tell me door was closed.

So now, I bought a wide gap magnetic switch and mounted it as it was the only way. Still the same SV and the same config. However, HA is now reporting the state in reverse order. When the magnets are together, it's open, and when they are not together, it's showing as closed. The regal person sold me a normally closed switch if I recall correctly. I already know that the switch is working in a different way to the old one.

This is my current HA config for the Sonoff SVs (they are the ones that started my HA journey)

Switch Config

    - name: "Garage Door"
      unique_id: 9b7b0191-22c6-40d3-b13d-83169773cb70
      icon: mdi:garage-variant
      state_topic: "stat/garagestate/POWER2"
      command_topic: "cmnd/SNOFF_GarageDoor/POWER"
      availability_topic: "tele/SNOFF_GarageDoor/LWT"
      qos: 1
      payload_on: "ON"
      payload_off: "OFF"
      payload_available: "Online"
      payload_not_available: "Offline"

Cover Config

mqtt:
  cover:
    - name: "GARAGE DOOR-1"
      unique_id: 3b1b5f70-6d87-40e9-a079-0e4a90e16252
      state_topic: "cmnd/garagestate/POWER2"
      command_topic: "cmnd/SNOFF_GarageDoor/POWER"
      availability_topic: "tele/SNOFF_GarageDoor/LWT"
      qos: 1
      payload_open: "ON"
      payload_close: "ON"
      payload_stop: "ON"
      payload_available: "Online"
      payload_not_available: "Offline"
      state_open: "OFF"
      state_closed: "ON"
      optimistic: false
      retain: false

I had thought just swapping the payload_on/payload close, i.e all ON become OFF and all OFF become ON, in the COVER config should reverse what HA is showing but it appears I am doing something wrong. As far as I know the Cover is what shows the state of the gate?

But it's been so long that I looked at HA (mines has been so very reliable and nothing needed adding or tweaking) that I lost what I had of my limited skills!

Ignore. It was indeed just the cover payloads/states that needed to be swapped around. However, reloading all YAML files didn't make it stick. Had to reboot HA for it to be applied. all good in the house again!!

 

[cjvzyl]

I need some advice on integrating an electric fence into HA. I have sorted the basics, but I'm stuck at the final step, so apologies for the long post. Here is the entire thing.

I used a Sonoff SV to get control of my Nemtek Merlin M18S energizer. I removed the resistor to isolate the relay as a dry contact. I connected up a 12V relay to the siren connector and the relay's normally open contact to GPIO14 on the SV. The SV has ESPHome flashed on it and so far it works perfectly. However, there is no easy way to see whether the energizer is actually armed/energising the fence except for physically looking at the LED indicator on the energizer. This means that when I switch the energizer on/off via Home Assistant, I have no way to know whether it actually turned on or not.

After a bunch of research, I decided the best, safest and neatest way to tackle this is by soldering two wires to the LED indicator, connecting those to an opto-isolator (I decided on the 4N25) and have the that signal to GPIO4 or GPIO5 whether the fence is armed or not. Simple enough. However, I know just enough about electronics and programming to be a danger to myself. Having done all of this, I am getting log data that I cannot square with what I am expecting or with what I know to fix.

1. I connected the opto-isolator directly to the LED indicator (pin 1 and 2). All the pin-outs ask for a current limiting resistor to pin 1; however, this is usually for higher voltage signals. So I opted to leave that out, because when I measure the voltage drop across the LED is was just over 1V (also, when the opto-isolator is connected the LED indicator no longer blinks - I assume that the opto-isolator is draining all the juice).
2. The opto-isolator's output is intermittent but constant even when the fence is not energised. What i mean by this is the signal I receive in the logs switches on-off very quickly. When the fence is armed 16 or 17 times per second; when unarmed 5 times every three seconds. I did not expect this as the indicator LED itself under normal circumstances flashes about every second and this is the signal that I had intended to interpret as a sensor.

So my question is: what is happening here? Is this an expected behaviour, but I just do not know how to interpret it? Or should I change my circuit slightly by adding something to cancel the 'noise' (I have no idea what I'm saying here - sorry!) - a pull-down resistor between the ground and live of the LED before the opto-isolator or some kind of capacitor (when I said I know just enough to be dangerous, this is what I'm talking about )? Is there a problem with my ESP programming not interpreting the signals correctly? I tried on_multi_click first but had not sensor output. With my current code I am at least getting a sensor value, but the value is inconsistent even after tweaking the milliseconds many times to try and catch the perfect mid-way.

Here is my truncated code for the flashed SV:

binary_sensor:
- platform: gpio
pin:
number: GPIO14
mode: INPUT_PULLUP
inverted: true
name: Alarm
device_class: tamper

- platform: gpio
pin:
number: GPIO4
inverted: False
mode: INPUT_PULLUP
id: good_LED
name: Good LED
device_class: power
entity_category: diagnostic
disabled_by_default: true
on_click:
- min_length: 0ms
max_length: 100ms
then:
- logger.log:
level: VERBOSE
format: "Armed"
- text_sensor.template.publish:
id: active
state: "Fence Armed"
- min_length: 200ms
then:
- logger.log:
level: VERBOSE
format: "Unarmed"
- text_sensor.template.publish:
id: active
state: "Fence Unarmed"

- platform: status
name: Status

switch:
- platform: gpio
pin: GPIO12
id: relay
- platform: template
icon: "mdi:fence-electric"
name: Fence Switch
turn_on_action:
- switch.turn_on: relay
- delay: 750ms
- switch.turn_off: relay

sensor:
- platform: wifi_signal
name: WIFI Strength
update_interval: '60s'

button:
- platform: restart
name: Restart

text_sensor:
- platform: wifi_info
ip_address:
name: IP Address

- platform: template
icon: mdi:information-outline
id: active
name: Armed

Here is some log output for when the fence is unarmed:
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON

As you can see, the sensor is not getting the right idea and mostly it just flickers between 'armed' and 'unarmed'.

Any advice would be appreciated. Please let me know if you need any clarification.

 

[deesef]

I need some advice on integrating an electric fence into HA. I have sorted the basics, but I'm stuck at the final step, so apologies for the long post. Here is the entire thing.

I used a Sonoff SV to get control of my Nemtek Merlin M18S energizer. I removed the resistor to isolate the relay as a dry contact. I connected up a 12V relay to the siren connector and the relay's normally open contact to GPIO14 on the SV. The SV has ESPHome flashed on it and so far it works perfectly. However, there is no easy way to see whether the energizer is actually armed/energising the fence except for physically looking at the LED indicator on the energizer. This means that when I switch the energizer on/off via Home Assistant, I have no way to know whether it actually turned on or not.

After a bunch of research, I decided the best, safest and neatest way to tackle this is by soldering two wires to the LED indicator, connecting those to an opto-isolator (I decided on the 4N25) and have the that signal to GPIO4 or GPIO5 whether the fence is armed or not. Simple enough. However, I know just enough about electronics and programming to be a danger to myself. Having done all of this, I am getting log data that I cannot square with what I am expecting or with what I know to fix.

1. I connected the opto-isolator directly to the LED indicator (pin 1 and 2). All the pin-outs ask for a current limiting resistor to pin 1; however, this is usually for higher voltage signals. So I opted to leave that out, because when I measure the voltage drop across the LED is was just over 1V (also, when the opto-isolator is connected the LED indicator no longer blinks - I assume that the opto-isolator is draining all the juice).
2. The opto-isolator's output is intermittent but constant even when the fence is not energised. What i mean by this is the signal I receive in the logs switches on-off very quickly. When the fence is armed 16 or 17 times per second; when unarmed 5 times every three seconds. I did not expect this as the indicator LED itself under normal circumstances flashes about every second and this is the signal that I had intended to interpret as a sensor.

So my question is: what is happening here? Is this an expected behaviour, but I just do not know how to interpret it? Or should I change my circuit slightly by adding something to cancel the 'noise' (I have no idea what I'm saying here - sorry!) - a pull-down resistor between the ground and live of the LED before the opto-isolator or some kind of capacitor (when I said I know just enough to be dangerous, this is what I'm talking about )? Is there a problem with my ESP programming not interpreting the signals correctly? I tried on_multi_click first but had not sensor output. With my current code I am at least getting a sensor value, but the value is inconsistent even after tweaking the milliseconds many times to try and catch the perfect mid-way.

Here is my truncated code for the flashed SV:

binary_sensor:
- platform: gpio
pin:
number: GPIO14
mode: INPUT_PULLUP
inverted: true
name: Alarm
device_class: tamper

- platform: gpio
pin:
number: GPIO4
inverted: False
mode: INPUT_PULLUP
id: good_LED
name: Good LED
device_class: power
entity_category: diagnostic
disabled_by_default: true
on_click:
- min_length: 0ms
max_length: 100ms
then:
- logger.log:
level: VERBOSE
format: "Armed"
- text_sensor.template.publish:
id: active
state: "Fence Armed"
- min_length: 200ms
then:
- logger.log:
level: VERBOSE
format: "Unarmed"
- text_sensor.template.publish:
id: active
state: "Fence Unarmed"

- platform: status
name: Status

switch:
- platform: gpio
pin: GPIO12
id: relay
- platform: template
icon: "mdi:fence-electric"
name: Fence Switch
turn_on_action:
- switch.turn_on: relay
- delay: 750ms
- switch.turn_off: relay

sensor:
- platform: wifi_signal
name: WIFI Strength
update_interval: '60s'

button:
- platform: restart
name: Restart

text_sensor:
- platform: wifi_info
ip_address:
name: IP Address

- platform: template
icon: mdi:information-outline
id: active
name: Armed

Here is some log output for when the fence is unarmed:
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:48][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:48][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state OFF
[17:58:49][D][text_sensor:064]: 'Armed': Sending state 'Fence Armed'
[17:58:49][D][binary_sensor:036]: 'Good LED': Sending state ON

As you can see, the sensor is not getting the right idea and mostly it just flickers between 'armed' and 'unarmed'.

Any advice would be appreciated. Please let me know if you need any clarification.

Step 1: put a resistor (470 ohms to 1k) in series from the led to the base of the transistor of the opto-coupler. You are currently sinking all the power going to the led directly to earth through the opto-coupler...

 

[dabbler]

Step 1: put a resistor (470 ohms to 1k) in series from the led to the base of the transistor of the opto-coupler. You are currently sinking all the power going to the led directly to earth through the opto-coupler...

You could try connect your LED and Opto-coupler input LED in series. May work?

 

[Gielie01]

I need some advice on integrating an electric fence into HA. I have sorted the basics, but I'm stuck at the final step, so apologies for the long post. Here is the entire thing.
*snip

Any advice would be appreciated. Please let me know if you need any clarification.

Read the LED with a photoresistor
Some inspiration
https://esphome.io/cookbook/power_meter.html

 

[cjvzyl]

Step 1: put a resistor (470 ohms to 1k) in series from the led to the base of the transistor of the opto-coupler. You are currently sinking all the power going to the led directly to earth through the opto-coupler...

I assumed that it wouldn't be necessary because I thought the voltage drop was low enough for the tolerance of the opto-isolator. You know what they say about assumptions.

You could try connect your LED and Opto-coupler input LED in series. May work?

Not really an option, unless I remove the circuit board and scratch out the traces so I can place it in series - something I would rather not do. However, that would probable have the same/similar effect to adding a resistor in series before the 4N25.

Read the LED with a photoresistor
Some inspiration
https://esphome.io/cookbook/power_meter.html

Thanks, Gielie. I did look at this option, but I would really like something that does not look very patched together, but would be neat. I would like something internal that I can hide neatly in a box.

 

[deesef]

I assumed that it wouldn't be necessary .... You know what they say about assumptions.

I know all about making an ASS of U and ME.
Not too worry; I've been called worse

I'm sure that you will get it working...

 

[McGuywer]

Check out tuya-local - Similar integration but I have had a lot more success with it and moved over all my Tuya based integrations to this one.

I have tried that, now I get this:



The Energy is there but incorrect.

 

[McGuywer]

Even changing to kWh does not make a difference:

 

[SauRoNZA]

Ok, so I am befok

Had to replace my old garage door motor. I had a SONOFF SV (Tasmota) connected to it and had setup the GPO14 to be a sensor to let me know when door is open / close. It worked well and was reliable

The new centurion garage door motor works slightly differently in that nothing moves along the track (like my old one) . I had put the magnet switch on the moving bit and it worked well to tell me door was closed.

So now, I bought a wide gap magnetic switch and mounted it as it was the only way. Still the same SV and the same config. However, HA is now reporting the state in reverse order. When the magnets are together, it's open, and when they are not together, it's showing as closed. The regal person sold me a normally closed switch if I recall correctly. I already know that the switch is working in a different way to the old one.

This is my current HA config for the Sonoff SVs (they are the ones that started my HA journey)

Switch Config

    - name: "Garage Door"
      unique_id: 9b7b0191-22c6-40d3-b13d-83169773cb70
      icon: mdi:garage-variant
      state_topic: "stat/garagestate/POWER2"
      command_topic: "cmnd/SNOFF_GarageDoor/POWER"
      availability_topic: "tele/SNOFF_GarageDoor/LWT"
      qos: 1
      payload_on: "ON"
      payload_off: "OFF"
      payload_available: "Online"
      payload_not_available: "Offline"

Cover Config

mqtt:
  cover:
    - name: "GARAGE DOOR-1"
      unique_id: 3b1b5f70-6d87-40e9-a079-0e4a90e16252
      state_topic: "cmnd/garagestate/POWER2"
      command_topic: "cmnd/SNOFF_GarageDoor/POWER"
      availability_topic: "tele/SNOFF_GarageDoor/LWT"
      qos: 1
      payload_open: "ON"
      payload_close: "ON"
      payload_stop: "ON"
      payload_available: "Online"
      payload_not_available: "Offline"
      state_open: "OFF"
      state_closed: "ON"
      optimistic: false
      retain: false

I had thought just swapping the payload_on/payload close, i.e all ON become OFF and all OFF become ON, in the COVER config should reverse what HA is showing but it appears I am doing something wrong. As far as I know the Cover is what shows the state of the gate?

But it's been so long that I looked at HA (mines has been so very reliable and nothing needed adding or tweaking) that I lost what I had of my limited skills!

Forget the payload it's the state_open and state_closed you want to change and flip around.

Or go into Tasmota (presumably) and update the state there to be the other way around.

 

[SauRoNZA]

Even changing to kWh does not make a difference:

View attachment 1799580

It's that just the total energy tracked?

So you'll either need to pump that into the Energy Dashboard so it can work it out for you day by day, or use Utility Meter to generate a sensor of this total data.

But it's also why I gave up on local_tuya because mapping this kak was painful between different devices.

Cloud power all the way.

 

[McGuywer]

It's that just the total energy tracked?

So you'll either need to pump that into the Energy Dashboard so it can work it out for you day by day, or use Utility Meter to generate a sensor of this total data.

But it's also why I gave up on local_tuya because mapping this kak was painful between different devices.

Cloud power all the way.

Yes, that is the total energy which is incorrect.

I have now tried tuya local, local tuya and official tuya.
I cannot get the energy to work. I would love to include it in the energy dashboard.