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
Following the guide I took a lot of the non-essential functionality out of the esphome.io template, and i think the person who did the pull simplified it further. I am now updating my version with some of the simplifications (eg that the “id:” values are only used within the device’s own yaml, and so don’t need to differentiate between multiple devices of the same type).
I guess here is a good place to post my latest version with all the bells and whistles I found and thought useful - but also many of the simplifications:
#
# I have a number of Aulec PC191HA smart plugs with Power Monitoring,
# ESPHome guide says to use "name_add_mac_suffix: true" to automatically add the
# MAC address to the device name, so you can use a single firmware for all devices.
# However, while MAC address is definitely unique, it is not at all intuitive,
# and since I already use static IP addresses, I append last octet of the device IP Address.
#
substitutions:
deviceIP: "109" # last octet of the IP Address
friendly_name: pc191ha-${deviceIP} # user-friendly devicename:
device_name: pc191ha_${deviceIP} # the device_id as used by HomeAssistant, including IP suffix
# the parameters used below (for ease of adjusting)
restore_mode: RESTORE_DEFAULT_ON # mode for when power is turned on
update_interval: "30s" # How often to measure and report energy values
esphome:
name: $friendly_name
bk72xx:
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.${deviceIP}
fast_connect: True
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "pc191ha Fallback Hotspot"
password: !secret wifi_ap_password
captive_portal:
web_server:
port: 80
#
# PC191HA basic switch operation - button, relay and LED
#
# 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
# so no point exposing these 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: $friendly_name button
id: button
device_class: window
# when button is pressed, toggle the switch on/off
on_press:
then:
- switch.toggle: relay # toggle the relay / switch
internal: True
light: # LED in the button (led1_pin: 26)
- platform: status_led
# name: $friendly_name Switch state
id: led
pin: P26
restore_mode: $restore_mode # default when power is turned on
internal: True
switch: # relay (rl1_pin: 6)
- platform: gpio
pin: P6
name: $friendly_name relay
id: relay
restore_mode: $restore_mode # default when power is turned on
# synchronise the LED with the relay
on_turn_on:
then:
- light.turn_on: led
on_turn_off:
then:
- light.turn_off: led
- platform: restart
name: $friendly_name Restart
#
# PC191HA sensors - power monitoring
#
sensor:
- platform: wifi_signal # report wi-fi signal strength from this end
name: $friendly_name WiFi Signal
id: ${device_name}_wifi_signal
update_interval: "120s" # how often to report wifi signal strength
- platform: uptime
name: $friendly_name Uptime
id: ${device_name}_uptime
update_interval: "120s"
# PC191HA includes a BL0937 chip for measuring power consumption
# and BL0937 is a variation of hlw8012, but using inverted SEL pin functionality
# Note that the first value reported should be ignored as inaccurate
- 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 # determine whether true reports Voltage
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: $update_interval # How often to measure and report values
### Decided that I want Power and Voltage reported each time (not swapping with Current).
# I can choose not to keep swapping SEL pin, instead setting change_mode_every to a
# sufficiently high value that it will take 4000 years to shange.
# This means I will have to calculate the value for current (as a template) from power / voltage
initial_mode: "VOLTAGE" # reports VOLTAGE or CURRENT
change_mode_every: 4294967295 # how many times to report before swapping
# Adjust according to the actual resistor values on board to calibrate the specific unit
voltage_divider: 770 # LOWER VALUE GIVES LOWER VOLTAGE
current_resistor: 0.001 # HIGHER VALUE GIVES LOWER WATTAGE
# how the power monitoring values are returned to ESPHome
voltage:
name: $friendly_name Voltage
id: voltage
unit_of_measurement: V
accuracy_decimals: 1
filters:
- skip_initial: 1
power:
name: $friendly_name Power
id: power
unit_of_measurement: W
accuracy_decimals: 1
filters:
- skip_initial: 1
- multiply: 0.97
- lambda: if (x < 0.01) {return 0;} else {return x;}
energy:
name: $friendly_name Energy
unit_of_measurement: Wh
accuracy_decimals: 1
filters:
- skip_initial: 1
# instead of alternating reporting Voltage and Current, I will report Current from a template
# current:
# name: $friendly_name Current
# unit_of_measurement: A
# accuracy_decimals: 2
# filters:
# - skip_initial: 1
# - multiply: 0.4250
# - lambda: if (x < 0.01) {return 0;} else {return x;}
- platform: template
name: $friendly_name Current
unit_of_measurement: A
accuracy_decimals: 2
update_interval: $update_interval
lambda: |-
return (id(power).state / id(voltage).state );
filters:
- skip_initial: 2 # give time for data to settle to avoid NaN
ESPHome-able (via Cloudcutter and LibreTiny). No need to open to flash.
Small form factor (fit 2 side-by-side )
Power Monitoring
I like the button being on the top for access
Oz Certified (as opposed to the Athom I moved over to after the Kogan’s and Brilliant’s failed)
Dirt cheap at $15 AUD.
Con’s:
Possibly “disposable devices” - who knows how long they will last? Based on other cheap devices, maybe not that long. Caps are a common culprit.
The end to end flash pipeline is still a little involved even though it’s wireless. Expect a Tuya convert style flash. The instructions are pretty good. When I hit issues it was mainly because I wasn’t following them properly . After you’ve done one it would be way faster for subsequent devices.
TODO:
More testing
Optimise config.
Long term review
Initial config is below. I copied / merged some stuff from the Athom config and bits from Don too.
Yeah. After a year I have had three of the Arlec IP44 versions die recently (only one of which was outside). All with same symptoms - they start to cycle on/off rapidly, which is not great for anything that might be connected to them plus caused a Tuya based device that was plugged into one of them to reset. Part of me is thinking about pulling them apart and working out what has gone to silicon heaven, but the other part of me is planning to just bin them.
In converting these devices to TuyaLocal I listed the dp_ids, which included a couple I didn’t implement:
dp_id 9 is countdown (toggle the switch after x minutes ?). This could be useful, but I am already doing that in my Node-RED automations. This seems to map to LocalTuya’s timer attribute.
dp_id 26 is fault, with valid values ov_cr, ov_vol, ov_pwr, ls_cr, ls_vol, and ls_pow. I think this maps to LocalTuya’s error and currently returns “off”, but not sure what I would actually do with a different value - after all I would only be looking at it when I know it’s not working
In LocalTuya HA integration (for the devices i haven’t upgraded yet)
child_lock is showing “unknown”, and well, I have no children
overcharge_cutoff (battery charging has finished ?) is showing “unknown”
On the other hand, I found ESPHome’s uptime, wifi_signal, restart and firmware to be relevant and useful
Good point - I admit I was being lazy. Just cracked one PC44HA open, and all the caps were visually ok ie no bulges etc. If I can be bothered I’ll take out the capacitors and test them one at a time - assumption being if I find a bad one, it will be common on all the switches.
Of course I don’t know how much variation there may be between individual units … but personally I only want to know whether my chest freezer is running or not.
Personally I would like to standardise on zigbee for any future device purchases, and so I haven’t bought a PC191HA v2 unit yet … but I do agree the Pro’s you mention are compelling - and nothing in zigbee that comes close
I am interested to compare your configuration, and try out any differences … though of course they are likely to be added functionality in the CB2S chip.
)
. After you’ve done one it would be way faster for subsequent devices.