It took me some time to figure out how to get the current, power, voltage setup as sensors rather than the default attributes with Tuya Loca with the Arlec Grid connect plug-in sockets. A step by step guide;
Interesting. I also have defined entities for the voltage, current and power when adding the Arlec plug-in socket to see what differences between using entities or attributes.
I do notice a few differences with your screen shots though. In your steps 8, 10 and 12 your images show a “Scaling factor” field which I don’t have. In your step 14 you show a “Sensors” category, where all my entities are listed under the “Controls”.
Both approaches seem to record history, and are easy to work with. After problems with HA getting flooded by messages I have reduced the number of devices connected, removed some of the lovelace cards that may have been taking more CPU time, and gone back to adding sensor templates in configuration.yaml (as in the “Energy monitoring values” section of LocalTuya documentation ) to reduce the amount of network messages needing to be processed.
that … and that I have noticed that my 3 Arlec smart plugs regularly disconnect and immediately reconnect to my shiny new ASUS RT-AX55 wifi AP - despite being located 2m from the AP with line of sight; and other devices with worse rssi remaining online >200 hours.
But, the weird thing is that it happens regularly at 25 past the hour, most hours, and only affects the Grid connect devices (with up-to-date Tuya firmware).
I have a few Gridconnect Smart Plugs (Energy Monitoring) that appear in the Tuya intergration but not the Local Tuya integration. In the Local Tuya instance - no devices are appearing.
API server region = eu
Client ID = Project client id
Secret = Project secret
User ID = Linked device uid
Do I need to manually add the devices? Or is something not working?
This was prompted by the teardown https://www.elektroda.com/rtvforum/topic3944452.html by jessemclachlan, which put me onto CloudCutter. CloudCutter not only works with the Tuya WB2S module (and several of the other newer chips Tuya have swapped to) but does it OTA, so no having to pry the units open and apply a soldering iron !
I used CloudCutter to cut it from Tuya cloud leaving the Tuya firmware; and then later used CloudCutter, LibreTuya and the libretuya-esphome fork of ESPHome to install a basic ESPHome firmware.
Still more to be done to give the same results as the Tuya firmware (especially calibrating the voltage reading ) but hopefully ESPHome will be more reliable than LocalTuya was for me.
esphome:
name: pc191ha-108
libretuya:
board: wb2s
framework:
version: dev
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: !secret esphome_api_encryption
ota:
password: !secret esphome_ota_password
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
use_address: 192.168.1.108
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "pc191ha-108 Fallback Hotspot"
password: "v8ag08b0GTNj"
captive_portal:
web_server:
port: 80
#
# PC191HA configuration
binary_sensor: # button (bt1_pin: 11)
- platform: gpio
pin: P11
name: "pc191ha-108_button"
id: pc191ha_108_button
device_class: window
on_press:
then:
- switch.toggle: pc191ha_108_relay # toggle the relay
light: # LED in the button (led1_pin: 26)
- platform: status_led
name: "pc191ha-108 Switch state"
id: pc191ha_108_led
pin: P26
switch: # relay (rl1_pin: 6)
- platform: gpio
pin: P6
name: "pc191ha-108_relay"
id: pc191ha_108_relay
on_turn_on:
then:
- light.turn_on: pc191ha_108_led
on_turn_off:
then:
- light.turn_off: pc191ha_108_led
# Example configuration entry for device BL0937 using inverted SEL pin functionality
sensor:
- platform: hlw8012
model: BL0937
sel_pin:
inverted: true
number: P24
cf_pin:
inverted: true # the logic of BL0937 is opposite from HLW8012
number: P7
cf1_pin:
inverted: true # the logic of BL0937 is opposite from HLW8012
number: P8
current:
name: "pc191ha-108 Current"
voltage:
name: "pc191ha-108 Voltage"
power:
name: "pc191ha-108 Power"
update_interval: 10s
change_mode_every: 3
Update: I converted two units of the same device, and have them running.
On one unit I added reporting the wi-fi signal strength (I have previously had devices drop off my WLAN), added restoring the previous state when powered on; and was refining the calibration of the Voltage and Amperage readings … when the I noticed that the firmware configuration wasn’t changing !
Firmware still appeared to compile and load OTA. But even when I trimmed it down to wifi only, it still reported the power readings and operated the switch !!!
I tried asking for help on discord, but that wasn’t helpful. I don’t want to lock up my other devices, if that is what has happened to the one which now wont update firmware.
So I have put this whole issue aside for a while. Maybe Libretuya-esphome will be updated soon, and maybe I’ll try from scratch again after a fresh install of Ubuntu 23.04.
Hi Don, I’ve managed to flash one of mine with a basic yaml, I was about to try and re flash with your yaml. Any progress on the more advanced yaml and overcoming the re-flashing bug?
Edit: I used what ever version of code for cloud cutter, ESPHome / libretuya was available yesterday. I can confirm although the OTA esp home update appears successful, on reboot the old firmware is still in place.
I now have a basic firmware (with no useful config like buttons and switches) on the device. Basically useless
My frustration with this issue and the response I received on discord resulted in me deciding to put the whole thing aside for a while.
After a week of being powered off; I powered them on again, and the new setting took ! I guess that I was being impatient and not giving enough time for the units to properly reset after flashing.
The result is that I have 2 units running ESPHome and returning values - but the values are not in the correct range, and so I have not modified my automations or flashed my other 3 arlec power plugs.
I guess its time I got back and experimented with the values for voltage_divider and current_resistor. This time giving each unit a full power cycle after flashing. I saw that someone suggested a method for draining the capacitor more quickly
I was planning to wait till I got reasonable values for voltage_divider and current_resistor (accepting that each unit would need individual calibration to be properly accurate anyway) before posting my final code, but I may as well post my current firmware yaml now. Hopefully my comments and researching the options I found and incorporated will be useful to others. Note that my device names include the last number of IP address (eg pc191ha-108) and so I have used yaml substitutions, so that I only need to change the value of deviceIP once at the top when I copy the yaml code to a different unit.
#
# Arlec PC191HA - power plug with energy monitoring
# Uses a Tuya WB2S module with BL0937 for measuring power consumption
#
# Note: My devices are named including the last part of their IP address (eg pc191ha-108),
# and so I have used sustitutions so that I can easily copy this yaml
# and need only change the deviceIP. You do not need to do this.
substitutions:
deviceIP: "108"
devicename: pc191ha-$deviceIP
deviceID: pc191ha_$deviceIP
esphome:
name: $devicename
libretuya:
board: wb2s
framework:
version: dev
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "HgoRlyg+sp+PXuiZ0h8fcSCxq+HxVp9hvmCAPwzMnW8="
ota:
password: !secret esphome_ota_password
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
use_address: 192.168.1.$deviceIP
fast_connect: True
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "pc191ha Fallback Hotspot"
password: "v8ag08b0GTNj"
captive_portal:
web_server:
port: 80
#
# PC191HA basic switch operation - button, relay and LED
#
# Pressing the button activates the switch, and the switch controls the light.
#
# Notes:
# - Button is momentary on - shows "on" in HA except for the moment the button is being pressed
# - LED should have same on/off state as the relay
# - Switch and relay are different names for the same thing
# - Home Assistant uses the status of the switch (also called relay), and so
# no point also exposing button and LED to HA - use internal: true option
# - There is also a wifi_LED, but it is not seen from outside the case
binary_sensor: # button (bt1_pin: 11)
- platform: gpio
pin: P11
name: $devicename button
id: ${deviceID}_button
device_class: window
# when button is pressed, toggle the switch on/off
on_press:
then:
- switch.toggle: ${deviceID}_relay # toggle the relay / switch
internal: True
switch: # relay (rl1_pin: 6)
- platform: gpio
pin: P6
name: $devicename relay
id: ${deviceID}_relay
restore_mode: RESTORE_DEFAULT_OFF
# synchronise the LED with the relay
on_turn_on:
then:
- light.turn_on: ${deviceID}_led
on_turn_off:
then:
- light.turn_off: ${deviceID}_led
- platform: restart
name: $devicename Restart
light: # LED in the button (led1_pin: 26)
- platform: status_led
name: $devicename Switch state
id: ${deviceID}_led
pin: P26
restore_mode: RESTORE_DEFAULT_OFF
internal: True
#
# PC191HA sensors - power monitoring
#
sensor:
# I found i can add reporting the wi-fi signal strength received by the device,
# which may be different from the wi-fi signal received by the Access Point.
# May help me in debugging wi-fi issues. Not necessary for operation of pc191ha.
- platform: wifi_signal
name: $devicename WiFi Signal
id: ${deviceID}_wifi_signal
update_interval: 50s # how often to report wifi signal strength
# PC191HA includes a BL0937 chip for measuring power consumption
# and BL0937 is a variation of hlw8012, but using inverted SEL pin functionality
- platform: hlw8012
model: BL0937 # note that the model must be specified to use special calculation parameters
sel_pin: # I believe that cf_pin reports either Voltage or Current depending on this select pin
inverted: true
number: P24
cf_pin: # current or voltage (ele_pin: 7)
inverted: true # the logic of BL0937 is opposite from HLW8012
number: P7
cf1_pin: # Power (vi_pin: 8)
inverted: true # the logic of BL0937 is opposite from HLW8012
number: P8
update_interval: 15s # How often to measure and report values
# PC191HA measures and returns Voltage OR Current according to the value of sel_pin,
# but it can change the value of sel_pin periodically
change_mode_every: 4 # how many times to report before swapping between
# reporting Voltage or Current.
# Note that the first value reported should be ignored as possibly inaccurate
# Adjust according to the actual resistor values on board to calibrate the specific unit
voltage_divider: 740 # LOWER VALUE GIVES LOWER VOLTAGE
current_resistor: 1.00 # HIGHER VALUE GIVES LOWER WATTAGE
# power is simply current x voltage, so needs no separate calibration
# how the power monitoring values are returned to ESPHome
current:
name: $devicename Current
id: ${deviceID}_current
unit_of_measurement: A
accuracy_decimals: 4
voltage:
name: $devicename Voltage
id: ${deviceID}_voltage
unit_of_measurement: V
accuracy_decimals: 1
power:
name: $devicename Power
id: ${deviceID}_power
unit_of_measurement: W
accuracy_decimals: 4
I have been pulling my hair out two, just read your post and shorted the main input pins and put a load on it to discharge the cap and now ota update works.
with the voltage is this not giving peak to peak instead off rms?
*** Edit ***
This discharge don’t work, it’s is random on times. But the new firmware from Libretiny now does OTA.
Just flashed and refreshed 10 devices.
Also if a device is bricked from this don’t do a manual flash institute, remove the wb2s. (RIP buspriate)
After a couple of days of trial and error attempting to calibrate one PC191HA against the TP-Link HS110 which is monitoring my freezer, I have come to the following values which give values <5% different:
voltage_divider: “779”
current_resistor: “0.00225”
It’s a tedious process …
using HA’s LibreTuya-ESPHome dashboard, I edit the .yaml file and install by OTA
5 to 10 minutes later the device comes back online, but still using the values in the previous firmware
turn power OFF and leave for >5 minutes (I haven’t tried to work out the exact time)
power ON and wait
5 to 10 minutes later the device comes back online, this time using the values in the installed firmware
Just updated my other PC191HA device. Same procedure, but only around 3 minutes for each delay. Maybe my first one is faulty ?
Notes re calibration:
I don’t have an any device for accurately measuring power usage, so tried comparing with another uncalibrated power plug.
I used the freezer because it has a load, though in my testing the load remained fairly constant. I plugged the freezer into PC191HA, into TP-Link HS110 (not calibrated), into wall power socket. I assume the difference between the actual load on the two plugs should be negligible.
I took screen dumps of the lovelace page showing values from both power plugs. I realise that they are not reporting to HA simultaneously, introducing some discrepancy.
I understand that Power (Watts) is Volts * Amps … but there is a major difference between the Wattage reported by both devices - the PC191HA shows about half the Watts for the same Volts and Amps !!! Not sure whether I should re-calibrate for Amps or Watts.
When the freezer motor is not working, the HS110 shows 0.03A and 1.7W - yet the PC191HA with above parameters shows 0.0000A and 0.0000W. I wonder if this is an indication of rounding error when doing arithmetic on very small numbers.
I don’t have an electrical/electronic background, so no idea about this
Flashing OTA is important for me, which brought me to cloudcutter and LibreTuya (now renamed as LibreTiny) in the first place
I do wish though that the ESPHome establishment were more open to the idea of adding support for the newer Tuya modules to ESPHome, rather than telling people to open their units and solder in older replacement chips.
Has anyone tried to implement the countdown_1 timer with these plugs?
I’ve had around 15 of these, just using localtuya, running for about a year with the help of this thread.
I’m happy with the power values I’m getting, but I’ve got a specific use case for using the timer that you can find in the tuya smartlife app. E.g. I want to send “Turn off plug and turn on again after 60 sec”. Normally this would be fine within HA - however the plug I’m talking about runs the router. Once that’s off, the HA server can’t communicate with it, etc.
Rather than log into there, keep my plug connected to the app, and utilise the timer there - I’d prefer to do it all in HA.
I’m presuming that there is a way, considering we have the countdown filed as part of the integration, but has anyone tried to use it before I go start digging?
Alright, ignore the above. It was easier than I thought.
For anyone else trying to get this working:
When you are adding the switch and sensors for the plug in the localtuya setup, just add another entity of type number, set it to id = 9 (details from tuya iot below).
When you have the device and entities in HA, go to the device and you’ll have 2 controls - a switch and a Timer (well a number but I called mine Timer).
Hit the switch THEN set the timer number. If you do it the other way round, the call to flick the switch sets the timer to 0 and it won’t work (it’ll flick the switch, but with no timer).
Back in March I reported here that I converted two of my Arlec PC191HA power switches to ESPHome firmware over-the-air.
Since then I have
(a) added a uptime and Wi-fi Signal fields to ESPHome YAML device definitions, and
(b) discovered that there is a different tuya-local integration (GitHub - make-all/tuya-local: Local support for Tuya devices in Home Assistant), and gave it a try. Using the Device_id and local_key values it detected PC191HA’s as “smartplugv2_energy” (a generic profile based on which DPs are exposed). All DPs were configured, and seem to fit nicely into existing Lovelace panels.
Both the PC191HA units running ESPHome and units under TuyaLocal have been stable, and an improvement. Time to standardise. It would love to remove tuya - but I have other tuya-based devices (particularly the Zemismart blind).
Anyway i just compared devices and found extra fields in the TuyaLocal definition for PC191-HAs.
I just came here after seeing your comment in the AU thread, so sorry this is late.
The extra entities in the Tuya version could easily be added to the ESPhome version, you just need to update your code a bit.
ie: to add a timer or ‘child lock’ function.
for the light entity in the Tuya version, the reason you don’t see that in the ESPhome version is because your ESPhome code has ‘internal: True’ which prevents the device from exposing this entity to HA.
‘Initial state’ is also configurable in ESPhome, your config lists ‘RESTORE_DEFAUL-OFF’. Now, I’m not sure (since I’ve never tried) as to whether or no this can be made to use a HA selector or not.
While I see ESPHome as my preferred platform going forward, I really am still just a beginner with it.
I know that I will have to dive into it (rather than just the brief skims to copy/paste bits of code which i have done so far) for much to stick in my old brain.
I am looking at a small home greenhouse project which I know one of my RasPis will handle easily - however it may be appropriate for ESPHome
) but hopefully ESPHome will be more reliable than LocalTuya was for me.
