Using the ESPHome dashboard, I have installed my device, edited configuration and installed firmware. It does work - just not every time !
I do the “Clean Build Files”, then Install selecting Wirelessly … and …
INFO Reading configuration /config/libretuya-esphome/pc191ha-109.yaml...
INFO Detected timezone 'Australia/Sydney'
INFO Generating C++ source...
INFO Compiling app...
Processing pc191ha-109 (board: wb2s; framework: arduino; platform: https://github.com/kuba2k2/libretuya.git)
--------------------------------------------------------------------------------
Library Manager: Installing esphome/ESPAsyncWebServer-esphome @ 3.0.0
INFO Installing esphome/ESPAsyncWebServer-esphome @ 3.0.0
Unpacking [####################################] 100%
Library Manager: [email protected] has been installed!
INFO [email protected] has been installed!
Library Manager: Resolving dependencies...
INFO Resolving dependencies...
Library Manager: Installing esphome/AsyncTCP-esphome
INFO Installing esphome/AsyncTCP-esphome
Unpacking [####################################] 100%
Library Manager: [email protected] has been installed!
INFO [email protected] has been installed!
Library Manager: Installing esphome/noise-c @ 0.1.4
INFO Installing esphome/noise-c @ 0.1.4
Unpacking [####################################] 100%
Library Manager: [email protected] has been installed!
INFO [email protected] has been installed!
Library Manager: Resolving dependencies...
INFO Resolving dependencies...
Library Manager: Installing esphome/libsodium @ 1.10018.1
INFO Installing esphome/libsodium @ 1.10018.1
Unpacking [####################################] 100%
Library Manager: [email protected] has been installed!
INFO [email protected] has been installed!
Library Manager: Installing bblanchon/ArduinoJson @ 6.18.5
INFO Installing bblanchon/ArduinoJson @ 6.18.5
Unpacking [####################################] 100%
Library Manager: [email protected] has been installed!
INFO [email protected] has been installed!
HARDWARE: BK7231T 120MHz, 256KB RAM, 1.03MB Flash
- framework-arduino-api @ 3.0.0-a4cbfc+sha.3a4cbfc
- framework-beken-bdk @ 0.0.0+v2021.06.07.sha.6491b8c
- library-flashdb@03500fa @ 3500.0.0-fa+sha.03500fa
- [email protected] @ 2.1.3-bdk+sha.33191e0
- [email protected] @ 6.0.0+sha.8b831c1
- tool-ltchiptool @ 2.0.2+sha.7559033
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
Library Manager: Installing DNSServer
Unpacking [------------------------------------] 0%
Unpacking [###---------------------------------] 8%
Unpacking [######------------------------------] 16%
Unpacking [#########---------------------------] 25%
Unpacking [############------------------------] 33%
Unpacking [###############---------------------] 41%
Unpacking [##################------------------] 50%
Unpacking [#####################---------------] 58%
Unpacking [########################------------] 66%
Unpacking [###########################---------] 75%
Unpacking [##############################------] 83%
Unpacking [#################################---] 91%
Unpacking [####################################] 100%
Library Manager: [email protected] has been installed!
Dependency Graph
|-- ESPAsyncWebServer-esphome @ 3.0.0
| |-- AsyncTCP-esphome @ 2.0.0
|-- DNSServer @ 1.1.0
|-- noise-c @ 0.1.4
| |-- libsodium @ 1.10018.1
|-- ArduinoJson @ 6.18.5
Compiling /data/pc191ha-109/.pioenvs/pc191ha-109/src/esphome/components/api/api_connection.cpp.o
Compiling /data/pc191ha-109/.pioenvs/pc191ha-109/src/esphome/components/api/api_frame_helper.cpp.o
Compiling /data/pc191ha-109/.pioenvs/pc191ha-109/src/esphome/components/api/api_pb2.cpp.o
Compiling /data/pc191ha-109/.pioenvs/pc191ha-109/src/esphome/components/api/api_pb2_service.cpp.o
...
lots of compilation messages including what I have been told are expected warning messages
...
Compiling /data/pc191ha-109/.pioenvs/pc191ha-109/bdk_ble_4_2/profiles/sdp/src/sdp_service.c.o
Compiling /data/pc191ha-109/.pioenvs/pc191ha-109/bdk_ble_4_2/profiles/sdp/src/sdp_service_task.c.o
Archiving /data/pc191ha-109/.pioenvs/pc191ha-109/libbdk_ble_4_2.a
Linking /data/pc191ha-109/.pioenvs/pc191ha-109/firmware.elf
|-- Image 1: firmware.elf
| |-- bk7231t_app_0x011000.rbl
| | |-- firmware.bin
| |-- bk7231t_app_0x011000.crc
| |-- bk7231t_app_0x129F0A.rblh
| |-- bk7231t_app.ota.rbl
| |-- bk7231t_app.ota.ug.bin
Building UF2 OTA image
|-- firmware.uf2
RAM: [==== ] 44.3% (used 116096 bytes from 262144 bytes)
Flash: [======= ] 69.7% (used 754796 bytes from 1083136 bytes)
========================= [SUCCESS] Took 41.23 seconds =========================
INFO Successfully compiled program.
INFO Connecting to 192.168.1.109
INFO Uploading /data/pc191ha-109/.pioenvs/pc191ha-109/firmware.uf2 (2608128 bytes)
Uploading: [============================================================] 100% Done...
INFO Waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
INFO Starting log output from 192.168.1.109 using esphome API
INFO Successfully connected to 192.168.1.109
[21:55:38][I][app:102]: ESPHome version 2023.1.0-dev compiled on Mar 5 2023, 21:34:35
[21:55:38][C][status_led:063]: Status Led Light:
[21:55:38][C][status_led:064]: Pin: D7
[21:55:38][C][wifi:504]: WiFi:
[21:55:38][C][wifi:362]: Local MAC: 38:1F:8D:F1:F2:1A
[21:55:38][C][wifi:363]: SSID: [redacted]
[21:55:38][C][wifi:364]: IP Address: 192.168.1.109
[21:55:38][C][wifi:366]: BSSID: [redacted]
[21:55:38][C][wifi:367]: Hostname: 'pc191ha-109'
[21:55:38][C][wifi:369]: Signal strength: -67 dB ▂▄▆█
[21:55:38][C][wifi:373]: Channel: 6
[21:55:38][C][wifi:374]: Subnet: 255.255.255.0
[21:55:38][C][wifi:375]: Gateway: 192.168.1.1
[21:55:38][C][wifi:376]: DNS1: 192.168.1.1
[21:55:38][C][wifi:377]: DNS2: 192.168.1.1
[21:55:38][C][logger:338]: Logger:
[21:55:38][C][logger:339]: Level: DEBUG
[21:55:38][C][logger:340]: Log Baud Rate: 115200
[21:55:38][C][logger:341]: Hardware UART: SERIAL2
[21:55:38][C][switch.gpio:076]: GPIO Switch 'pc191ha-109 relay'
[21:55:38][C][switch.gpio:099]: Restore Mode: restore defaults to OFF
[21:55:38][C][switch.gpio:031]: Pin: D2
[21:55:38][C][gpio.binary_sensor:015]: GPIO Binary Sensor 'pc191ha-109 button'
[21:55:38][C][gpio.binary_sensor:015]: Device Class: 'window'
[21:55:38][C][gpio.binary_sensor:016]: Pin: D5
[21:55:38][C][light:104]: Light 'pc191ha-109 Switch state'
[21:55:38][C][restart:076]: Restart Switch 'pc191ha-109 Restart'
[21:55:38][C][restart:078]: Icon: 'mdi:restart'
[21:55:38][C][restart:099]: Restore Mode: restore defaults to OFF
[21:55:38][C][hlw8012:037]: HLW8012:
[21:55:39][C][hlw8012:038]: SEL Pin: D6
[21:55:39][C][hlw8012:039]: CF Pin: D1
[21:55:39][C][hlw8012:040]: CF1 Pin: D0
[21:55:39][C][hlw8012:041]: Change measurement mode every 3
[21:55:39][C][hlw8012:042]: Current resistor: 107.0 mΩ
[21:55:39][C][hlw8012:043]: Voltage Divider: 710.0
[21:55:39][C][hlw8012:044]: Update Interval: 10.0s
[21:55:39][C][hlw8012:045]: Voltage 'pc191ha-109 Voltage'
[21:55:39][C][hlw8012:045]: Device Class: 'voltage'
[21:55:39][C][hlw8012:045]: State Class: 'measurement'
[21:55:39][C][hlw8012:045]: Unit of Measurement: 'V'
[21:55:39][C][hlw8012:045]: Accuracy Decimals: 1
[21:55:39][C][hlw8012:046]: Current 'pc191ha-109 Current'
[21:55:39][C][hlw8012:046]: Device Class: 'current'
[21:55:39][C][hlw8012:046]: State Class: 'measurement'
[21:55:39][C][hlw8012:046]: Unit of Measurement: 'A'
[21:55:39][C][hlw8012:046]: Accuracy Decimals: 5
[21:55:39][C][hlw8012:047]: Power 'pc191ha-109 Power'
[21:55:39][C][hlw8012:047]: Device Class: 'power'
[21:55:39][C][hlw8012:047]: State Class: 'measurement'
[21:55:39][C][hlw8012:047]: Unit of Measurement: 'W'
[21:55:39][C][hlw8012:047]: Accuracy Decimals: 5
[21:55:39][C][hlw8012:048]: Energy 'pc191ha-109 Energy'
[21:55:39][C][hlw8012:048]: Device Class: 'energy'
[21:55:39][C][hlw8012:048]: State Class: 'total_increasing'
[21:55:39][C][hlw8012:048]: Unit of Measurement: 'Wh'
[21:55:39][C][hlw8012:048]: Accuracy Decimals: 6
[21:55:39][C][total_daily_energy:023]: Total Daily Energy 'pc191ha-109 Total Daily Energy'
[21:55:39][C][total_daily_energy:023]: Device Class: 'energy'
[21:55:39][C][total_daily_energy:023]: State Class: 'total_increasing'
[21:55:39][C][total_daily_energy:023]: Unit of Measurement: 'kWh'
[21:55:39][C][total_daily_energy:023]: Accuracy Decimals: 7
[21:55:39][C][homeassistant.time:010]: Home Assistant Time:
[21:55:39][C][homeassistant.time:011]: Timezone: 'AEST-10AEDT,M10.1.0,M4.1.0/3'
[21:55:39][C][captive_portal:088]: Captive Portal:
[21:55:39][C][web_server:150]: Web Server:
[21:55:39][C][web_server:151]: Address: 192.168.1.109:80
[21:55:39][C][mdns:106]: mDNS:
[21:55:39][C][mdns:107]: Hostname: pc191ha-109
[21:55:39][C][ota:093]: Over-The-Air Updates:
[21:55:39][C][ota:094]: Address: 192.168.1.109:8892
[21:55:39][C][api:138]: API Server:
[21:55:39][C][api:139]: Address: 192.168.1.109:6053
[21:55:39][C][api:141]: Using noise encryption: YES
[21:55:39][C][wifi_signal.sensor:009]: WiFi Signal 'pc191ha-109 WiFi Signal'
[21:55:39][C][wifi_signal.sensor:009]: Device Class: 'signal_strength'
[21:55:39][C][wifi_signal.sensor:009]: State Class: 'measurement'
[21:55:39][C][wifi_signal.sensor:009]: Unit of Measurement: 'dBm'
[21:55:39][C][wifi_signal.sensor:009]: Accuracy Decimals: 0
[21:55:39][C][lt.component:013]: LibreTuya:
[21:55:39][C][lt.component:014]: Version: 0.12.6+sha.8f447a4
[21:55:39][C][lt.component:015]: Loglevel: 3
[21:55:48][D][sensor:127]: 'pc191ha-109 Power': Sending state 0.07434 W with 5 decimals of accuracy
[21:55:48][D][sensor:127]: 'pc191ha-109 Total Daily Energy': Sending state 0.00002 kWh with 7 decimals of accuracy
[21:55:48][D][sensor:127]: 'pc191ha-109 Energy': Sending state 0.00021 Wh with 6 decimals of accuracy
[21:55:58][D][hlw8012:082]: Got power=0.1W, voltage=220.3V
[21:55:58][D][sensor:127]: 'pc191ha-109 Voltage': Sending state 220.32599 V with 1 decimals of accuracy
[21:55:58][D][sensor:127]: 'pc191ha-109 Power': Sending state 0.07434 W with 5 decimals of accuracy
[21:55:58][D][sensor:127]: 'pc191ha-109 Total Daily Energy': Sending state 0.00002 kWh with 7 decimals of accuracy
[21:55:58][D][sensor:127]: 'pc191ha-109 Energy': Sending state 0.00041 Wh with 6 decimals of accuracy
[21:56:08][D][hlw8012:082]: Got power=0.1W, voltage=219.7V
[21:56:08][D][sensor:127]: 'pc191ha-109 Voltage': Sending state 219.73062 V with 1 decimals of accuracy
[21:56:08][D][sensor:127]: 'pc191ha-109 Power': Sending state 0.07434 W with 5 decimals of accuracy
[21:56:08][D][sensor:127]: 'pc191ha-109 Total Daily Energy': Sending state 0.00002 kWh with 7 decimals of accuracy
[21:56:08][D][sensor:127]: 'pc191ha-109 Energy': Sending state 0.00062 Wh with 6 decimals of accuracy
Looks great … appears to successfully compile, and to upload … except that it doesn’t incorporate the changes I just made in the configuration yaml.
In the sensor: section for the BL0937 I had changed to “voltage_divider: 730”, yet the install log above still shows “[21:55:39][C][hlw8012:043]: Voltage Divider: 710.0”.
I had also changed “update_interval: 18s” yet the log is still updating every 10s
Current is still logging " 22:21:00 [D] [sensor:127] ‘pc191ha-109 Current’: Sending state 0.00127 A with 5 decimals of accuracy" despite my adding “filters: -multiply: 100.0” to scale it close to the correct 1.34A.
Is it possibly that the firmware image is too big for the device ? Flash: 69.7% used. I seem to recall reading somewhere that updating OTA requires the full old firmware running until control is passed to the new firmware - ie they both have to fit into memory simultaneously. Also recall one of the ESPHome compiles (probably from command line somewhere) that the size of the resulting object file could be reduced.
I am having the exact same problem, with the same device pc191ha-109. This may be specific to this device my other libretiny deta downlights update just fine.
If that doesn’t do it, power the plug off for 10 minutes, then power on and wait another 10 minutes for it to boot. I can’t imagine why it takes so long
I have determined (by trial and error) a value for voltage_divider of about 720.
I seem to recall that Volts x Amps = Watts … but not for the PC191HA. I can adjust current_resistor to give the same number of Amps as one of my TP-Link plugs OR to give the same number of Watts.
I’m having another go at this, and documenting as i go. BTW I am using the Home Assistant LibreTiny add-on (which I believe is a fork of ESPHome).
The unit I have been using for testing seems to be taking longer and longer to come back online after a firmware install. I have compiled and installed firmware, then waited ONE HOUR for the PC191HA to reboot and come back online. Next install took 2 HOURS for the device to come back online … still running the old firmware.
I understand these are small, cheap, and therefore “slow” devices - but even so 10 minutes to come online after any reboot seems excessive.
It seems this particular unity is going faulty, since the other one I flashed only takes a couple of minutes to come back online.
I found that when both my PC191HA devices come back online after installing firmware, it is still running the previous firmware. You can check this using the HA LibreTiny ESPHome add-on’s [Logs] button and checking the compiled date & time in the header that is returned…
INFO Starting log output from 192.168.1.108 using esphome API
INFO Successfully connected to 192.168.1.108
[15:00:55][I][app:102]: ESPHome version 2023.5.0-dev compiled on Jun 4 2023, 13:48:42
[15:00:55][C][status_led:064]: Status Led Light:
Turn power off at the wall socket for about 10 minutes, then when the device comes back online hopefully it will be running the latest firmware.
The BL0937 chip’s cf1_pin returns Power (Watts); and cf_pin returns either Current (Amps) or Voltage (Volts) depending on the value of sel_pin. ESPHome assumes you will want both current and voltage, and so changes sel_pin after change_mode_every reports.
One side-effect is that the first value returned after sel_pin is changed is inaccurate and so should be dropped - but that is left as an exercise for the reader, otherwise HA records a spike whenever the power switches on.
Finding a reasonable value for voltage_divider was fairly easy; but I cannot find a value for current_resistor that returns reasonable values for Amps and Watts. I have ended up choosing to optimise for Watts since this will fit my automations better; and so the current_resistor value gives a reasonable value for power (Watts) and is meaningless if current (Amps) is reported.
Since I am not interested in the (inaccurate) readings for current, there is no point the BL0937 swapping sel_pin to provide it. It seems you cannot leave sel_pin unchanged by simply setting change_mode_every: 0 … you need to set it to the biggest number it will take.
To make it easier to adjust the parameters, I have made just all the parameters into substitutions at the top of the yaml file.
And so herewith is my current yaml file for Arlec PC191HA power switch:
substitutions:
deviceIP: "108" # last octet of the IP Address
devicename: pc191ha-$deviceIP
deviceID: pc191ha_$deviceIP
# the parameters used below (for ease of adjusting)
restore_mode: RESTORE_DEFAULT_ON # mode for when power is turned on
wifi_update_interval: "60s" # how often to report wifi signal strength
# hlw8012 does the power monitoring and reporting
hlw8012_update_interval: "10s" # How often to measure and report values
### Decided that I want Power and Voltage reported each time (not swapping with Current).
hlw8012_initial_mode: "VOLTAGE" # reports VOLTAGE or CURRENT
hlw8012_change_mode_every: "4294967295" # do NOT swap between reporting Volts or Amps
# Adjust according to the actual resistor values on board to calibrate the specific unit
hlw8012_voltage_divider: "769"
hlw8012_current_resistor: "0.000835"
esphome:
name: $devicename
libretiny:
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
#
# 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: $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
light: # LED in the button (led1_pin: 26)
- platform: status_led
name: $devicename Switch state
id: ${deviceID}_led
pin: P26
restore_mode: $restore_mode
internal: True
switch: # relay (rl1_pin: 6)
- platform: gpio
pin: P6
name: $devicename relay
id: ${deviceID}_relay
restore_mode: $restore_mode # default when power is turned on
# 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
#
# PC191HA sensors - power monitoring
#
sensor:
- platform: wifi_signal # report wi-fi signal strength from this end
name: $devicename WiFi Signal
id: ${deviceID}_wifi_signal
update_interval: $wifi_update_interval # 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 # 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: $hlw8012_update_interval # 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
initial_mode: $hlw8012_initial_mode # reports VOLTAGE or CURRENT
change_mode_every: $hlw8012_change_mode_every # how many times to report before swapping between
# reporting Voltage or Current. Note that the first value reported should be ignored as inaccurate
# Adjust according to the actual resistor values on board to calibrate the specific unit
voltage_divider: $hlw8012_voltage_divider # LOWER VALUE GIVES LOWER VOLTAGE
current_resistor: $hlw8012_current_resistor # HIGHER VALUE GIVES LOWER WATTAGE
# power is simply current x voltage, so needs no separate calibration
### except that the pc191ha doesn't follow that formula.
### Setting current_resistor to give an accurate Amperage does NOT also give the correct Wattage
###
# 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 converted all my devices to Esphome back in April. This included 8 off PC191HA plugs with the wb2s board. Now I also had an issue with new firmware not taking. I just can’t recall if this was on the Arlec plugs or the other Athom and generic plugs I converted? It was an energy plug as calibration on one device was a real pain. Took me a while to realise what was going on! I thought I documented this but no, anyway I recall the fix was to pull the plug out after writing the firmware and do a clean boot up. New firmware was loaded every time.
Don, thanks for your work on this! I’ve used your template and got the voltage and watts dialled in to match Watts Clever readings almost exactly.
After reading your hassle trying to get the Amps reading accurate as well, I wondered if we can just use the Watts and Voltage to calculate that and send it back to HA, and turns out we can so here is an updated bottom section of your template that does that. Also added uptime because why not.
# how the power monitoring values are returned to ESPHome
voltage:
name: $devicename Voltage
id: ${deviceID}_voltage
unit_of_measurement: V
accuracy_decimals: 1
filters:
- skip_initial: 2
power:
name: $devicename Power
id: ${deviceID}_power
unit_of_measurement: W
accuracy_decimals: 2
filters:
- skip_initial: 2
- platform: template
name: $devicename Current
id: ${deviceID}_current
unit_of_measurement: A
accuracy_decimals: 2
update_interval: $hlw8012_update_interval
lambda: |-
return (id(${deviceID}_power).state / id(${deviceID}_voltage).state);
filters:
- skip_initial: 2
- platform: uptime
name: $devicename Uptime
id: ${deviceID}_uptime
update_interval: $hlw8012_update_interval
I am still very new at ESPHome and hadn’t come across Uptime yet, or the skip_initial; and haven’t even started to get my head around lambda. Your code works great.
My high-school science said Amps x Volts = Watts … which is why I was so frustrated trying to find a value for current_resistor which would fit the formula. It then makes me very suspicious about the data that is returned - but hey, I really only want to know whether the connected device is on or off (e.g. is the phone charger is still charging (drawing current)).
G’day all, discovered this very useful thread and have flashed 5 of my Arlec’s, another 15 to go!
One of the really frustrating things is that the new firmware just won’t stick most times. I have tried pulling the plug for 10 mins. There is another thread which says hold 5 secs/unplug for 5 secs/plug back then release - that didn’t quite guarantee the firmware would stick either.
Has anyone found a always-works method to ensuring the firmware sticks? Very challenging trying to adjust the calibration values without the firmware sticking!
The other issue is that with the exact same settings, I get 2 quite difference outcomes on 2 Arlecs. One would be spot on in terms of V in the 238-250V range, the other one would start off and stay around 211-200V and not budge from that range. Tring to fix the second one through tweaks of the voltage_divider setting is what I am trying to do with the updating of the firmware.
That is what I have found too. The unit I did most of my initial testing on, needed to be unplugged from the wall for ever longer periods (up to 9 hours) before powering on would activate the downloaded firmware. Rather a pain … but apparently only an issue for the Arlec PC191HA’s.
As for voltage_divider, I am still using the value and work-around suggested by @dftvrgbhyjnukmil above.
One of my 5 PC191HA’s suddenly started playing up last week - giving unexpected voltage readings when it wasn’t dropped off the wi-fi … so I just binned it @jcmleng is it only one of your units giving strange values, and how old is it ?
@donburch888 , thanks mate. Its comforting to know that I am not the only one being driven to the wall with this! I have flashed 5 thus far. All 5 are about 18 months old, bought in the same 2 month window.
In all 5, the devices have come back online in a matter of minutes. Power cycling helps to reboot and bring the device back online. As each device had an IP assigned, I found that adding a manual IP setting in the yaml helped the device come back quicker, vs leaving out the manual IP setting and letting the device find the IP - the router ended up using the old IP anyway.
Of the first 4, if I recall:
2 were “OK” 1st time, meaning I got to the 238-250V range on the first go and its stayed OK since.
the other 2 required reflashing. Can’t quite recall what method worked but somehow, I’ve got them in the same 238-250V range with the firmware changed once.
My 5th is giving me weird results.
focusing on V again, I have swung from 220 to under 200, now its at 270
none of the methods worked to make the new firmware stick (but see below)
the V value changed in some subsequent flashes ie from 220 to say 195, without the firmware version changing, so changing nothing CAN change the V value - that really makes no sense to me
some of the V values also changed when I changed the voltage_divider value, but the firmware version stays the same.
However, I have found that if you run “rename hostname” from the 3 dots in ESPHome, say from “Device-x” to “Device-x-1”, ESPHome recompiles the entire firmware and loaded an updated firmware. So I renamed the hostname, changed the voltage_divider in the yaml and uploaded the firmware, I went from 195V to 270V. Not great but it is a way to trick ESP to run a full recompile and install a new firmware.
I then changed the hostname from “Device-x-1” back to “Device-x”, thinking it would do the same. However, the firmware did not change and the compile was a very short version (the tree diagram pops up earlier), but the V value seems to have changed depending on the voltage_divider value. I am thinking that ESP might have picked up the old build files for “Device-x” in the original compile, made the change to voltage_divider, hence no firmware update.
I am just about to try re-doing the hostname change but to run Clean Build Files first, so that ESP has no old file to work with and see what happens.
There has to be a logical reason for all this … will keep having a crack until I run out of steam and will post results.
@donburch888 , a truly frustrating night! After successfully updating the firmware by renaming the hostname, could not replicate the changing of the firmware again. So am stuck with the firmware which uses voltage_divider = 770, and shows V ~210V, which is clearly wrong.
Tried renaming the hostname by adding a version no, completely changing the hostname, running the clean build files, nothing worked.
The strange part is that no matter what I tried, the compiler logs still show the same firmware above, the same hostname living-adsb-1-esp, the same voltage_divider = 770. This is then reflected in the ESP webpage for the device IP.
Looks like the compiler is referring to some old yaml and/or ignores the new yaml, despite the logs showing that it reads through the new yaml version. So, the firmware still carries the old values when it uploads to the device OTA. Trying to power cycle the device etc to make the firmware stick then has no impact because the firmware has fundamentally not been updated.
Will try tomorrow to delete the device in ESPHome and start the device all over again to try to flush out the old config yaml which is driving the build of the firmware.
Do you know how I can get the device back to the kickstart stage prior to the 1st upload of the firmware?
Very frustrating because the actual firmware build and process is a good one, the compile and OTA updates are pretty quick. It becomes a problem when the 1st firmware loaded yields the wrong readings - can’t then fix that with new settings because the firmware refuses to update. Will log an issue in GitHub if I don’t get anywhere tomm!
If it is only one unit, my guess is that it has gone faulty, and you may be wasting your time with it. At least put that problematic one aside for now. Several threads (esp the Australia electrically certified hardware thread have multiple reports of (all brands of) power plugs such as these going faulty not long after end of the warranty period.
I also use Manual IP addresses, especially for the power plugs which I am likely to relocate as needed. They also come online quicker because of not having to negotiate with DHCP.
Your firmware build log doesn’t mention the date and time you did the build - but I am sure it was after the “Feb 8 2024, 18:37:44” listed at the top of the run log … probably just before the [23:14:26] timestamp on that same first line of run log ?
Sorry, I think you maybe confusing the compile operation “log” from on your HA machine, with the run operation “log” from the device.
The new firmware did upload correctly… but the device IS still running the previous version of the firmware / yaml confiuration file.
In case of an error during the upload, it makes sense for the device to store the new firmware file and verify that it uploaded correctly - before overwriting the old firmware.
Normally this would be done automatically at the end of the upload - but it appears the PC191HA has a problem with activating the new firmware.
After the firmware has uploaded and the device has reset, it almost always starts up with the old firmware - not the new firmware which did upload correctly.
The device needs to be disconnected from the power for a variable length of time. Length of time seems to increase with each firmware update.
When powered on, the device may appear to pause for a while before reconnecting to the wi-fi - this seems to be when the new firmware is activated.
Use the HA ESPHome add-on’s [Logs] button to show the firmware’s version and compiled date/time. It is that first line in green text on your run log above
If the new firmware isn’t activated, you just have to wait longer . Go back to step 2.
Yes, this is very frustrating, and has taken me quite a while to work out what must be happening. Arlec PC191HA seems to be the only device I am aware of which does not automatically activate the new firmware after an upload; so I doubt there is much that the ESPHome / libreTiny developers can (or will) do about it for only one device.
I hope that this explanation makes sense, and that it can significantly reduce your frustration with what is otherwise not a bad bit of equipment.
It is clear that a new firmware IS actually uploaded into the device - the logs show that. However, as that first green line refers to the existing installed firmware, does that not mean that no new firmware was generated but the old firmware compile on Feb 8 18:37 was re-uploaded into the device? Thats how I read that portion of the log.
This makes sense. The INFO lines were interesting - line 4 shows the connection to the new hostname but line 5 handshakes with the existing hostname. That also corresponds with no change to the Visit webpage - it just refers to the old hostname despite renaming the hostname. It seems to keep referring to the old files. Am wondering if there is somewhere in the ESPHome folder which can be flushed out (other than Clean Build Files).
Back to the drawing board with this! Another thing I noticed is the device shows offline, even though it is clearly online and operational. My other devices which are OK and have no new firmware flashed are all online. Are you referring to this Online status in your steps above? Meaning, if I flashed now, pull out the plug and let it sit for say 1-2 days, when I plug it back, it should show online + the new firmware??
I’ll park this device for now and come back to it!
The challenge is for every device I flash, it WILL flash, but I am rolling the dice when it comes to the accuracy of the sensors, using the same offset values. It can either be completely OK/in range, in which case it can be used immediately. OR it can be off by 20-40V and I cannot recalibrate it because of the firmware behaviour. meaning that the plug is only good for switching devices on/off and not power monitoring … maybe thats the signal from above to work through the good devices and the duds, and have the duds replaced with ZB devices!
Ahhh, yes. Honestly I haven’t bothered looking at them before - but I have tried to avoid creating extra device profiles which I know will only confuse me down the track It does look like the log is picking up some values from the HA machine’s config file (with the new values), and receiving some (old) values from the device. Confusing !
I have not noticed devices showing as offline when they are actually connected. Is ESPHome showing two devices with both the old and new hostnames ? Possibly another case of ESPHome looking for a device with the new hostname … which isn’t online because the device is still announcing itself with its old hostname (which ESPHome is not expecting ?) At least you can still access the device directly by its IP address (http://192.168.1.41)
I believe that mixing values from the local config file and from the device is confusing; and messages could be worded better … but normally (for other devices) the new firmware would have updates, and there would be no differences to confuse users. Worth reporting on GIThub - but I wouldn’t expect it to be given any priority unless other devices also have the same problem with updating firmware automatically.
No need to upload again (unless you want different values than are in your latest uploaded firmware).
If you had left it unplugged when you finished last night, it may well start now with that pause (activating the new firmware) before the LED starts flashing indicating it is connecting to wi-fi.
Ha ! I found another device which seemed to do this, so have added my explanation to this github issue
Apart from your device #5 (which i suspect has gone faulty) I think the others will be reasonably close with the same parameters. Mine are fairly close; allowing for manufacturing tolerances, and them being on different fuse circuits around the house. Admittedly I am not too worried about accuracy - just whether my appliances are on or off
Hopefully that was only #5. You should be able to recalibrate your other devices … just keep an eye out for the firmware activating.
Unfortunately there isn’t much choice yet in Zigbee power switches, especially in the compact size
The firmware is Feb 8, 2242 which had the voltage_divider at 850 (vs the original 770), still no change to the V, so I think #5 is now just an on/off switch …
I must have done another 4-5 installs since, so it may take me another 2-3 days to cycle through the updates, which I might as well do to see what actually happens …
About to fire off the next one … see how that goes. Now that I have experienced “the long reboot”, will have to the calibration, one step at a time.
Re: ZB, I have a fair number from Ali which has worked well, sensors are far more sensitive to changes and costs <$10 a pop. I don’t want to take the easy way out and replace all these Arlec’s. Prefer to mess around with them, use what I can of it until it breaks, then replace. Perverse definition of “fun”!
But thanks for your input - have learnt a lot from it!
Also, #5, with the higher voltage_divider value of 850 may not quite be out given that the current voltage across all my other plugs - a hodge podge of Arlec’s unflashed, flashed and ZB are all showing 211 - 221V - that really surprises me!
Update: @donburch888 , after working through 15 or so plugs, noticed something interesting this morning. I reflashed this plug yesterday 11 Feb 24 at 1416, initially, then 1619, when the voltage needed adjusting. It was quite strange when the new values kicked in after the 2nd flash (the voltage corrected noticeably), but the firmware remained unchanged. Unplugged for 5 hours, still not take, Left it overnight, still no take this morning.
bottom right shows the older version, which lines up with what the ESP Web UI is showing
This was the same with another device, where the sensor values changed after the 2nd flash, the Web UI showed no changed, but the device card shows 2 versions.
What this then means is that we should ignore what the webUI is telling us, especially if the voltage sensors show corrected values after a reflash and instead go with what the Device Info in ESPHome is showing.
Would be good if you could check this on your Arlec plugs and the other device which you said also would not immediately take a firmware update.
Very pleased with this, as it means that technically, the new firmware appears to kick in immediately, even though the web UI says otherwise!
It does look like the log is picking up some values from the HA machine’s config file (with the new values), and receiving some (old) values from the device. Confusing !
