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.
All the extra’s I’ve added shouldn’t depend on the CB2S (most of it I pinched from the Anthom config which is another chip altogether (ESP8266). It’s all ESPHome level stuff.
You might like to look over adopting the “Total Energy” and “Total Daily Energy” for example.
I’ve also updated my config to include some of those calibrations and other bits.
I looked into Tuya’s dp_id 17 add_ele and discovered that it reports incremental power used since the last time it was reported … so particularly dependent on frequency of reporting (when my devices were dropping off my wi-fi) and that all values are captured and database updated (at the time I was getting ingress errors in my log).
And the history from one of my TP-Link HS110’s using TP-Link KASA integration (looks similar to Tuya) doesn’t inspire confidence…
However I have nothing to loose by trying out the ESPHome / PC191HA Energy values thanks
Wow, the firmware might be the same, but your CB2S chip’s pin numbering is way different from my WB2S chip !
Also I’m not seeing where status_led is used
Compiled with only one section commented out - I’ll come back to that later.
Installed, and device rebooted with firmware compiled 2 days ago … so no change to the unwritten “power off for a random time to get PC191HA to activate the uploaded firmware”. Further testing tomorrow…
Not entirely sure myself but seem to recall both red and blue led flashes when I was in the initial flashing process.
So probably the blue one is used for regular state indications and the red one for “warnings”. This could possibly be specific to my plug version.
I understand that the version 1 of PC191HA has 2 LEDs - the one we can see in the button, and apparently another inside the case which the factory uses to indicates the wi-fi status. Since I don’t want to open any up (at least while still under warranty) I never bothered programming it - what is the point of giving a visual indication that can’t be seen ?
My guess is that the “status_led” may refer to that internal LED, and so it doesn’t matter if nothing is using it. Of course assuming that v2 is the same as v1
I just bought a 4-pack of the PC191HA version 2, and can confirm that the Blue LED is used to indicate the switch’s ON/OFF state, and a Red LED blinks fast or slow to indicate that it is pairing.
I also found that all 4 of my devices took at least 3 attempts before they paired. Curiously the device’s LED would often stop blinking at about 1:50 on the countdown, but most often the Grid Connect app would simply time out. The MAC addresses were not consecutive, and all have firmware 1.3.5
I did have a go at this before, but didn’t get it to work. Thank you for showing the correct split between include and device.yaml. YES, working nicely … except that the v1 and v2 devices use different pin numbers … maybe i can nest includes.
)
. After you’ve done one it would be way faster for subsequent devices.
thanks