Closed HA-TB303 closed 1 year ago
I have the same issue though I have noticed that it only seems to affect light domain entities. Entities in the switch domain seem to work fine. I got around this by creating a template switch in home assistant. This still switches the light entity on and off but adding to apps.yaml instead of the original light entity fixes the updating problem on the display for me.
Yes, you are right. I just tested again to verify and indeed only light entities are effected. Switch works fine. Your solution is a nice work-around, but you can not dimm a switch:(
Yes, you are right. I just tested again to verify and indeed only light entities are effected. Switch works fine. Your solution is a nice work-around, but you can not dimm a switch:(
Yep, true. Hopefully the bug can be fixed, Odd that it only affects lights and not switches though.
Indeed. Hopefully @sairon is still willing and able to check this bug.
Thanks for your findings, folks, I probably have some anecdotal evidence of the same issue as well, yet I haven't done any debugging yet. It's quite strange it only affects lights, so I'll look deeper into it, thanks for the hint. Can't promise any ETA, but it's on my radar.
Thanks @sairon. Did some more experimenting last night... I think actually that the problem still remains with switch entities after all. Operating the switch from the panel seems to update as it should but if the switch is operated from elsewhere it doesn't update the state on the panel. Light entities don't update at all when operated from either the panel or elsewhere. Not sure if this helps at all...
Thanks for all your work on this. Love the Lovelace panel but not keen on Tasmota so this project is a real bonus for my setup.
On lights the "limit" of how many you can put in 1 gridcard seems to be 4. If I put 1-3 lights in the card the issue does not occur, it starts when adding the 4th light entity. I have done some extensive testing : https://github.com/joBr99/nspanel-lovelace-ui/issues/392#issuecomment-1234471994
Can flash current development version and test with this one?
FlashNextion http://nspanel.pky.eu/lui.tft
Edit: wanted to post this on https://github.com/joBr99/nspanel-lovelace-ui/issues/392 lol
Uploaded the new firmware. The issue is still the same. You should be able to reproduce this with multiple light entities on the same gridcard. I tried this on a totally different HA instance in another network and I am having exactly the same issue.
Wasn't able to repoduce this with tasmota even with more than 4 entites.
Can you update the appdaemon backend to latest main, restart appdaemon and test again?
I have no newer appdeamon version available. Restart was already done.
Did you test with esphome? I am aware it works fine with tasmota (a little slower though).
not appdaemon, the lovelace app in the hacs store
https://docs.nspanel.pky.eu/faq/#how-to-upgrade-from-a-release-to-the-current-development-version
Also latest:
yeah, you need to update to the development version/main
https://docs.nspanel.pky.eu/faq/#how-to-upgrade-from-a-release-to-the-current-development-version
click redownload, select main, wait for the select menu to be selectable again, click download
then restart appdaemon
version number should change to the hash of the commit (cc3ed54)
Downloaded main
restarted appdeamon and I still have the same issue.
ok, my theory was that esphome is sending the messages too fast, causing a buffer overflow on nextion
with the dev version I implemented a dedub for the mqtt messages so the backend won't send the same messages twice, but apparrently this wasn't the issue, I'm out again no idea
@sairon is esphome logging unexpected serial output from the panel?
in case there is an error on the nextion screen it will return error codes, for example 0x24 for buffer overflows
22:37:45.211 MQT: tele/tasmota_NsPanelTerrasse/RESULT = {"nextion":"bytes('24')"}
I can reproduce the issue with release 3.4.0 of the backend component and NS Panel screens, but I didn't spotted it on latest dev branch and NS Panel screen from the link in comment (http://nspanel.pky.eu/lui.tft)
I was testing with 4 light on one card and alarm icon on screensaver
Can flash current development version and test with this one?
FlashNextion http://nspanel.pky.eu/lui.tft
Edit: wanted to post this on https://github.com/joBr99/nspanel-lovelace-ui/issues/392 lol
If I remember correctly our latest result was that it only occures with more than 4 lights.
If I remember correctly our latest result was that it only occures with more than 4 lights.
Aha, I see, so I have a bit different setup with lights
Anyway I had a glitch on screensaver with alarm state icon (top left corner) which is now gone, while using dev branch codes
I was trying to look into this issue tonight but I still don't have an idea why this is happening. I've hooked up a logic analyzer to the TFT pins to see what's going on when this issue happens but I don't see any data corruption on the serial line. Here's a short session when trying to reproduce the issue - toggling the light "houby" from the HA web three times - states should go ON->OFF->ON, but after the last change the icon stayed blue:
[21:58:21][D][nspanel_lovelace:106]: Sending custom command: entityUpd~Obývák~1|1~light~light.lustr~~17299~Lustr~0~light~light.lustr_nocni~~17299~Lustr noční~0~light~light.lustr_rgb~~17299~Lustr RGB~0~switch~switch.hifi~~17299~HiFi~0~light~light.houby~~65222~Houby~1~light~light.rgb~~17299~RGB~0
[21:58:21][D][nspanel_lovelace:106]: Sending custom command: entityUpdateDetail~light.houby~~65222~1~disable~disable~disable~Color~Teplota barvy~Jas~disable
[21:58:22][D][nspanel_lovelace:106]: Sending custom command: entityUpd~Obývák~1|1~light~light.lustr~~17299~Lustr~0~light~light.lustr_nocni~~17299~Lustr noční~0~light~light.lustr_rgb~~17299~Lustr RGB~0~switch~switch.hifi~~17299~HiFi~0~light~light.houby~~17299~Houby~0~light~light.rgb~~17299~RGB~0
[21:58:22][D][nspanel_lovelace:106]: Sending custom command: entityUpdateDetail~light.houby~~17299~0~disable~disable~disable~Color~Teplota barvy~Jas~disable
[21:58:23][D][nspanel_lovelace:106]: Sending custom command: entityUpd~Obývák~1|1~light~light.lustr~~17299~Lustr~0~light~light.lustr_nocni~~17299~Lustr noční~0~light~light.lustr_rgb~~17299~Lustr RGB~0~switch~switch.hifi~~17299~HiFi~0~light~light.houby~~65222~Houby~1~light~light.rgb~~17299~RGB~0
[21:58:23][D][nspanel_lovelace:106]: Sending custom command: entityUpdateDetail~light.houby~~65222~1~disable~disable~disable~Color~Teplota barvy~Jas~disable
The same can be seen on the serial line - notice that both first two and last two rows (change to the ON state) are identical. There is no unexpected output received on the TX line (i.e. from the Nextion FW).
55 BB 00 01 65 6E 74 69 74 79 55 70 64 7E 4F 62 C3 BD 76 C3 A1 6B 7E 31 7C 31 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 6C 75 73 74 72 7E EE 8C B4 7E 31 37 32 39 39 7E 4C 75 73 74 72 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 6C 75 73 74 72 5F 6E 6F 63 6E 69 7E EE BD A4 7E 31 37 32 39 39 7E 4C 75 73 74 72 20 6E 6F C4 8D 6E C3 AD 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 6C 75 73 74 72 5F 72 67 62 7E EE 8C B4 7E 31 37 32 39 39 7E 4C 75 73 74 72 20 52 47 42 7E 30 7E 73 77 69 74 63 68 7E 73 77 69 74 63 68 2E 68 69 66 69 7E EE 93 82 7E 31 37 32 39 39 7E 48 69 46 69 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 68 6F 75 62 79 7E EE 9F 9E 7E 36 35 32 32 32 7E 48 6F 75 62 79 7E 31 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 72 67 62 7E EE 8F 97 7E 31 37 32 39 39 7E 52 47 42 7E 30 67 19
55 BB 5F 00 65 6E 74 69 74 79 55 70 64 61 74 65 44 65 74 61 69 6C 7E 6C 69 67 68 74 2E 68 6F 75 62 79 7E 7E 36 35 32 32 32 7E 31 7E 64 69 73 61 62 6C 65 7E 64 69 73 61 62 6C 65 7E 64 69 73 61 62 6C 65 7E 43 6F 6C 6F 72 7E 54 65 70 6C 6F 74 61 20 62 61 72 76 79 7E 4A 61 73 7E 64 69 73 61 62 6C 65 9B F8
55 BB 00 01 65 6E 74 69 74 79 55 70 64 7E 4F 62 C3 BD 76 C3 A1 6B 7E 31 7C 31 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 6C 75 73 74 72 7E EE 8C B4 7E 31 37 32 39 39 7E 4C 75 73 74 72 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 6C 75 73 74 72 5F 6E 6F 63 6E 69 7E EE BD A4 7E 31 37 32 39 39 7E 4C 75 73 74 72 20 6E 6F C4 8D 6E C3 AD 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 6C 75 73 74 72 5F 72 67 62 7E EE 8C B4 7E 31 37 32 39 39 7E 4C 75 73 74 72 20 52 47 42 7E 30 7E 73 77 69 74 63 68 7E 73 77 69 74 63 68 2E 68 69 66 69 7E EE 93 82 7E 31 37 32 39 39 7E 48 69 46 69 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 68 6F 75 62 79 7E EE 9F 9E 7E 31 37 32 39 39 7E 48 6F 75 62 79 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 72 67 62 7E EE 8F 97 7E 31 37 32 39 39 7E 52 47 42 7E 30 AD F6
55 BB 5F 00 65 6E 74 69 74 79 55 70 64 61 74 65 44 65 74 61 69 6C 7E 6C 69 67 68 74 2E 68 6F 75 62 79 7E 7E 31 37 32 39 39 7E 30 7E 64 69 73 61 62 6C 65 7E 64 69 73 61 62 6C 65 7E 64 69 73 61 62 6C 65 7E 43 6F 6C 6F 72 7E 54 65 70 6C 6F 74 61 20 62 61 72 76 79 7E 4A 61 73 7E 64 69 73 61 62 6C 65 1B D5
55 BB 00 01 65 6E 74 69 74 79 55 70 64 7E 4F 62 C3 BD 76 C3 A1 6B 7E 31 7C 31 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 6C 75 73 74 72 7E EE 8C B4 7E 31 37 32 39 39 7E 4C 75 73 74 72 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 6C 75 73 74 72 5F 6E 6F 63 6E 69 7E EE BD A4 7E 31 37 32 39 39 7E 4C 75 73 74 72 20 6E 6F C4 8D 6E C3 AD 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 6C 75 73 74 72 5F 72 67 62 7E EE 8C B4 7E 31 37 32 39 39 7E 4C 75 73 74 72 20 52 47 42 7E 30 7E 73 77 69 74 63 68 7E 73 77 69 74 63 68 2E 68 69 66 69 7E EE 93 82 7E 31 37 32 39 39 7E 48 69 46 69 7E 30 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 68 6F 75 62 79 7E EE 9F 9E 7E 36 35 32 32 32 7E 48 6F 75 62 79 7E 31 7E 6C 69 67 68 74 7E 6C 69 67 68 74 2E 72 67 62 7E EE 8F 97 7E 31 37 32 39 39 7E 52 47 42 7E 30 67 19
55 BB 5F 00 65 6E 74 69 74 79 55 70 64 61 74 65 44 65 74 61 69 6C 7E 6C 69 67 68 74 2E 68 6F 75 62 79 7E 7E 36 35 32 32 32 7E 31 7E 64 69 73 61 62 6C 65 7E 64 69 73 61 62 6C 65 7E 64 69 73 61 62 6C 65 7E 43 6F 6C 6F 72 7E 54 65 70 6C 6F 74 61 20 62 61 72 76 79 7E 4A 61 73 7E 64 69 73 61 62 6C 65 9B F8
I might revise this issue later, possibly compare Tasmota end ESPHome setups, but for the time being, I've added a workaround that might help getting rid of this annoyance. It exploits the fact that the panel pages are stateless, so transferring all the commands twice should not cause any issues (please correct me if I'm wrong, @joBr99). This workaround is on by default, but can be disabled by setting use_missed_updates_workaround
option to false
.
Ok, I will test this later this weekend. Thanks!
Had a moment of enlightenment today and realized that the root cause might be in the timing. Turns out the ESPHome component is actually too fast when compared with Tasmota :nerd_face:
I confirmed this theory by taking another look at the waveforms on the logic analyzer, finding out that the two messages sent right after another when light status is changed (entityUpd
and entityUpdateDetail
) are looking almost like a single message. This was also reason why switches were not affected, because there is no entityUpdateDetail
issue for them. After adding a short delay to the MQTT message callback, the issue is gone, which I validated using a simple stress test mocking fast subsequent status updates. The previous workaround improved the situation, yet there were still some missed events. I also checked that with Tasmota there's always ~100 ms "natural" delay between messages, but "artificial" 75 ms wait in my component seems to works as well. It seems that complex on_incoming_message
callbacks can also introduce such a delay, mitigating the issue, so it still kinda makes sense to add an option for disabling this delay.
@joBr99 It seems that sometimes the Nextion firmware can't cope with messages sent shortly after another (still had some issues with 50 ms delays, 75 ms and more seems to be working), ignoring the first entityUpd
, or at least a part of it (could be the cause why this happens only with >3 lights). There always needs to be some delay between messages, although the protocol doesn't define such requirement.
Yes, this is something that I also thought of, maybe we are to fast and we are fillig up the serial buffer faster than the stm32 can handle.
Hi, I have tried this. Made sure the panel has the latest display firmware (http://nspanel.pky.eu/lui-release.tft) the lastet apdeamon version and the lastet version of nspanel lovelace UI. Then I cleaned the build files in esphome and reflashed (OTA) the esphome firmware on the panel using this config;
substitutions:
devicename: nspanelbadk
friendly_devicename: NSPanel Badkamer
panel_recv_topic: "tele/nspanelbadk/RESULT"
panel_send_topic: "cmnd/nspanelbadk/CustomSend"
esphome:
name: $devicename
esp32:
board: esp32dev
wifi:
networks:
- ssid: !secret esphome_wifi_ssid
password: !secret esphome_wifi_password
# Logger. Disable the temperature sensor etc. to focus on the HMI development
logger:
level: DEBUG
logs:
sensor: WARN
resistance: WARN
text_sensor: WARN
ntc: WARN
ota:
safe_mode: true
# API. Add api_pwd to your secrets.yaml.
api:
services:
- service: upload_tft
variables:
url: string
then:
- lambda: |-
id(nspanel).upload_tft(url);
# Service to play a rtttl tone
- service: play_rtttl
variables:
song_str: string
then:
- rtttl.play:
rtttl: !lambda "return song_str;"
# Service to send a command directly to the display. Useful for testing
- service: send_command
variables:
cmd: string
then:
- lambda: "id(nspanel).send_custom_command(cmd.c_str());"
# Service to pusblish to mqtt used for refreshin the panel
- service: publish_to_recv_topic
variables:
cmd: string
then:
- mqtt.publish:
topic: $panel_recv_topic
payload: !lambda "return cmd;"
# Service to send a command wake the screen
- service: wake
then:
- lambda: 'id(nspanel).send_custom_command("wake");'
# Service to send a command to show screensaver (some of the values are hardcoded)
- service: show_screensaver
then:
- mqtt.publish:
topic: $panel_recv_topic
payload: '{"CustomRecv":"event,sleepReached,cardGrid"}'
# Service to navigate to screen
- service: navigate_to_page
variables:
page: string
then:
- mqtt.publish_json:
topic: $panel_recv_topic
payload: |-
root["CustomRecv"] = "event,buttonPress2,navigate." + page + ",button";
# Service to send a command disable screensaver
- service: disable_screensaver
then:
- lambda: 'id(nspanel).send_custom_command("timeout~0");'
# Service to send a command enabled screensaver
- service: enable_screensaver
then:
- lambda: 'id(nspanel).send_custom_command("timeout~20");'
# Service to send a command wake the screen
- service: dim_0_to_100
variables:
intensity: string
then:
- lambda: 'id(nspanel).send_custom_command("dimmode~"+intensity+"~100");'
# Service to send a command To show the screen of a specific like
- service: show_entity
variables:
entity: string
title: string
then:
- lambda: 'id(nspanel).send_custom_command("pageType~popupLight~" + title + "~" + entity);'
# Service to send a command To show the screen of a specific like
- service: notify_on_screensaver
variables:
line1: string
line2: string
then:
- lambda: 'id(nspanel).send_custom_command("notify~" + line1 + "~" + line2);'
- rtttl.play: "short:d=4,o=5,b=100:16e6"
# Service to send a command To show the screen of a specific like
# interaction of the buttons are on implemented yet
- service: notify_fullscreen
variables:
title: string
description: string
button1: string
button2: string
time_secs: string
then:
# show notification screen
- lambda: 'id(nspanel).send_custom_command("pageType~popupNotify");'
# set values on notification screen
# color defined as number created in binary and converted to decimal (rrrrggggbbbbaaaa)
- lambda: 'id(nspanel).send_custom_command("entityUpdateDetail~id~"+ title + "~65535~" + button1 +"~3840~" + button2 + "~61440~" + description + "~65535~" + time_secs);'
- rtttl.play: "scale_up:d=32,o=5,b=100:c,c#,d#,e,f#,g#,a#,b"
# Uart for the Nextion display
uart:
tx_pin: 16
rx_pin: 17
baud_rate: 115200
# Functionality for the Nextion display
external_components:
- source:
type: git
url: https://github.com/sairon/esphome-nspanel-lovelace-ui
ref: dev
components: [nspanel_lovelace]
mqtt:
id: mqtt_client
broker: !secret mqtt_ip
username: !secret mqtt_username
password: !secret mqtt_password
keepalive: 1s
nspanel_lovelace:
id: nspanel
mqtt_recv_topic: $panel_recv_topic
mqtt_send_topic: $panel_send_topic
sensor:
# Internal temperature sensor, adc value
- platform: adc
id: ntc_source
pin: 38
update_interval: 10s
attenuation: 11db
# Internal temperature sensor, adc reading converted to resistance (calculation)
- platform: resistance
id: resistance_sensor
sensor: ntc_source
configuration: DOWNSTREAM
resistor: 11.2kOhm
# Internal temperature sensor, resistance to temperature (calculation)
- platform: ntc
id: temperature
sensor: resistance_sensor
calibration:
b_constant: 3950
reference_temperature: 25°C
reference_resistance: 10kOhm
name: $friendly_devicename Temperature
output:
# Buzzer for playing tones
- platform: ledc
id: buzzer_out
pin:
number: 21
# Rtttl function for buzzer
rtttl:
id: buzzer
output: buzzer_out
switch:
# Physical relay 1
- platform: gpio
name: $friendly_devicename Relay 1
id: relay_1
pin:
number: 22
on_turn_on:
# show a light on the panel when we swich on the light
# - lambda: 'id(nspanel).send_custom_command("pageType~popupLight~[TITLE TO SHOW ON SCREEN]~[ENTITY NAME]");'
- lambda: 'id(nspanel).send_custom_command("pageType~popupLight~Light 1~light.bed_light");'
on_turn_off:
# send to screensaver when switch off the light
- mqtt.publish:
topic: $panel_recv_topic
payload: '{"CustomRecv":"event,sleepReached,cardGrid"}'
# Physical relay 2
- platform: gpio
name: $friendly_devicename Relay 2
id: relay_2
pin:
number: 19
on_turn_on:
# show a light on the panel when we swich on the light
- lambda: 'id(nspanel).send_custom_command("pageType~popupLight~Light 2~light.bed_light2");'
on_turn_off:
# send to screensaver when switch off the light
- mqtt.publish:
topic: $panel_recv_topic
payload: '{"CustomRecv":"event,sleepReached,cardGrid"}'
# Turn screen power on/off. Easy way to configure the screen power control, but this should not be used from HA, as all components must be re-initialized afterwards. For lights, names of lights etc. this practically means that the state must change once to happen.
- platform: gpio
name: Screen Power
id: screen_power
entity_category: config
pin:
number: 4
inverted: true
restore_mode: ALWAYS_ON
# Binary sensors
binary_sensor:
# Left button below the display
- platform: gpio
name: $friendly_devicename Left Button
pin:
number: GPIO14
inverted: true
id: left_button
on_press:
then:
- switch.turn_on: relay_1
# Right button below the display
- platform: gpio
name: $friendly_devicename Right Button
pin:
number: GPIO27
inverted: true
id: right_button
on_press:
then:
- switch.toggle: relay_2
It responds a little better now, but I am still missing a lot of status updates.
OK, reopening this ticket so I can gather more feedback. If status misses happen in your setup, please send here the following:
mosquitto_sub -h YOUR_MQTT_BROKER_IP -t "cmnd/nspanel/CustomSend" -t "tele/nspanel/RESULT" | ts "%.s"
@HA-TB303 Could you please try to reproduce it again and attach the missing logs? Just with the device configuration alone I am not able to reproduce it in my environment.
There's been no activity for the past two months and I haven't encountered the issue since implementing the workaround either. Closing it as resolved for now.
Hi,
I have been trying https://github.com/joBr99/nspanel-lovelace-ui with both Tasmota and your esphome component and I am having some issues with status change misses on the nspanel display. It does not matter of the status changes from home assistant or from the nspanel itself.
Reproduction: Configure a grid panel with external lights from Home Assistant like:
Then turn the light on and off from Home Assistant repeatedly and notice the misses. I have been debugging this with help from joBr99 here, bit no luck sofar: https://github.com/joBr99/nspanel-lovelace-ui/issues/392
This issues does not occur when using tasmota and the exact same config in adddeamon.
My ESPhome config (which is nearly identical to your example config)
Short video that "proves" the issue, Pay attention to the light on the far right (Vanity light)
https://user-images.githubusercontent.com/9609805/184479529-e59e42af-810f-4b1c-909c-5a6f439bea84.mp4