Open Hellis81 opened 2 years ago
I know I'm a bit late to this, but you can use the on_touch
from base component and send the results to a json-like text_sensor, so you can work with that sensor as a dictionary in HA.
Something like this:
display:
- id: disp1
platform: nextion
on_touch: # This is triggered when any component flagged with "Send Component Id" on it's touch events is pressed/released
- lambda: |-
char ontouch_json[128];
sprintf(ontouch_json, "{\"page_id\": %i, \"component_id\": %i, \"event_type\": %i}", page_id, component_id, touch_event);
nextion_touch_event->publish_state(ontouch_json);
text_sensor:
- id: nextion_touch_event
name: Nextion Touch Event
platform: template
update_interval: never
internal: false
This is the result from Developer Tools / Templates:
{% set nextion_touch_event = states("sensor.nextion_touch_event") | from_json if has_value("sensor.nextion_touch_event") else {"page_id": "unknown", "component_id": "unknown", "event_type": "unknown"} %}
nextion_touch_event: {{ nextion_touch_event }}
Page Id: {{ nextion_touch_event.page_id }}
Component Id: {{ nextion_touch_event.component_id }}
Event type: {{ ("PRESS" if nextion_touch_event.event_type == 0 else "RELEASE") if is_number(nextion_touch_event.event_type) else "Unknown" }}
Results:
nextion_touch_event: {'page_id': 0, 'component_id': 7, 'event_type': 1}
Page Id: 0
Component Id: 7
Event type: RELEASE
It looks a bit ugly on the device's page:
You could try to send an array/list to a regular sensor and it will look a bit better, although less human readable.
Interesting. Thank you for this.
I managed to find a workaround that is almost the same but requires a bit more manual work.
In the HMI/TFT I added a variable on each page. On each component/button I added a on touch event that updates the variable with the switch name.
So clicking on a light will give the variable the value light.bedroom_light
.
In ESP-Home I then added a listener to listen on this variable that is then forwarded to HA.
HA has a sensor that also gets the value light.bedroom_light
, an automation can then trigger on this and use {{trigger}} to make it easy in HA automations.
And lastly the Nextion on release event clears the variable again and this will be forwarded all the way to HA.
But what you have here is slightly less convenient in HA but a lot easier in Nextion. Good find!
Describe the problem you have/What new integration you would like I would like a change in the Nextion integration. The reason is that many of us can't squeeze enough in the ESP to get what we want from our displays/NS panels. Currently adding "buttons" means you add this kind of code:
I noticed however even without this yaml the Nextion display sends a message to ESP-Home saying:
What if we don't include page and component_id in the yaml and just have a "Nextion sensor" that is exposed to Home Assistant. Perhaps a sensor with state
page=2, component=23, type=press
then release. That way we can do all the automations in HA instead of loading the ESP full of yaml that is only button clicks.With the above we would have one sensor that captures any "clicks". What we have today is perhaps 20 sensors just to get the buttons to work.
Another change I would love to see is a sensor with the current page number. The reason is again to get fewer sensors in ESP-Home.
Imaging a sensor saying
page0
. In Home Assistant we add a template sensor with an array like this:and then we add another with componenet1 for all pages.
So the above sensor will change between several states depending on the page, and I think that can be used to push the correct states to each Nextion field.
Please describe your use case for this integration and alternatives you've tried: I tried using the logger and send that to Home Assistant but I could not get it to work. I posted my test on the community page: https://community.home-assistant.io/t/sonoff-nspanel-smart-scene-wall-switch-by-itead-coming-soon-on-kickstarter/332962/623
Additional context
Whoever does this change will probably be a hero to all NS panel owners who is currently dreading the 68.4% limit.