Setup loop behavior
Closed this issue · 7 comments
Hello,
So far I've been using awtrix, but I'm very enthusiastic about your project with the connection to HA.
With awtrix, I always have a lot of text stutters, so I'm just trying a comparable setup with your project.
But I somehow fail to set up a fixed loop behavior. I do not want to compare both projects in detail, but I think its somehow useful also for other beginners with your project.
I use the display to regularly display some room information, such as temperature and humidity.
This should simply be repeated at regular intervals.
clock (300s) -> room 1 (room name, temp, hum, co2) one time -> room 2 (room name, temp, hum, co2) one time -> room 3 (room name, temp, hum, co2) one time -> back to beginning with clock: clock for 300s.
Well, for the standard loop I have created a HA automation; in a sequence the screens are created. I have used a sequence, because there seems to be no other chance to specify a specific order of the messages/icons.
But I am not able to setup the described behavior above.
The room information is repeated all the time (room 1, room 2, room 3, room 1) and I think when the clock_interval is reached, the display jumps back to the clock from any position in the loop.
Its possible to setup this scenario?
If not yet, from your point of view, does an implementation make sense?
Additionally some other messages pop up, e.g. garage open - these messages shall be placed at the end of the standard loop and should not influence it. There could be a message with standard priority, which can be added at the end of the loop; but there could also be a prio message which should be shown directly.
Do you plan an implementation like this?
When I actually add a new screen with the HA service, its located "somewhere" in the sequence, but not at the end of the existing loop.
I have now written a lot of text, I would be happy about a feedback or discussion.
EsphoMaTrix is totaly dynamic, so there is no concept like a loop. But there is no specific order of the screens. You have to distinguish them by the icons or add a text to each value. Basically there is a stack of screens that are displayed in sequence. This loop is interrupted by regular time displays. A screen is removed from the stack when its lifetime has expired. A screen remains on the stack if it is to display a new value. You can force a screen to be displayed with force_screen. If an additional screen is to be displayed, it is inserted somewhere on the stack.
But you can get results close to your scenario.
In HA i've got an automation like this:
alias: EHMTX state display
description: update on each new state
trigger:
- platform: state
entity_id: sensor.001818a992bc04_wind_speed
id: room1_temp
- platform: state
entity_id: sensor.001818a992bc04_actual_temperature
id: room2_temp
- platform: state
entity_id: sensor.tankerkoenig_datteln_friedrich_ebert_str_73_diesel
id: room1_hum
condition: []
action:
- service: esphome.ulanzi_screen
data:
icon_name: "{{trigger.id}}"
text: >-
{{trigger.to_state.state}}{{trigger.to_state.attributes.unit_of_measurement}}
mode: parallel
max: 15
So every time the sensor gets a new state the display is refreshed witrh the new values.
On esphome you have to define icons according to your trigger ids, because every icon is like a screen in your loop..
If you like to have equal icons for each room you have to define the same icon with different ids. e.g.:
icons:
- id: room1_temp
file: temp.gif
- id: room2_temp
file: temp.gif
or with different icons per room
icons:
- id: room1_temp
file: temp1.gif
- id: room2_temp
file: temp2.gif
The timing is flexible, you can tweak a lot of settings.
Yet there is no plan (on my side) to redesign the screen handling, but this issue goes in your direction Reference screen by name/id instead of icon #48
Thanks for your fast and detailed answer!
I am using your project since 2 days and its really cool.
Your summary of the esphomatrix concept is really helpful and agrees with my current understanding of your implementation. It has advantages, but also disadvantages in case you like a "structured" and repeating information on the display.
Perhaps some input about my realization until now.
Trigger conditions to update the data for each room, like co2, hum, temperature.
I have not implemented it like your example - I have specified a fix update interval of 5 minutes - otherwise, in case there is no value change for a longer time (its the case for temperature & humidity) the screen lifetime expires and is removed from stack.
...
trigger:
- platform: time_pattern
minutes: "/5"
id: timer
alias: Aktualisiere alle 5 Minuten
- platform: state
entity_id:
- binary_sensor.esphomatrix1_status
from: "off"
to: "on"
for:
hours: 0
minutes: 0
seconds: 12
id: connected
...
The action part triggers a sequence to setup the correct order of the screens.
...
sequence:
# Wohnzimmer
- service: esphome.esphomatrix1_screen
data:
icon_name: wohnzimmer
text: "WOHNZIMMER"
- delay: 5
- service: esphome.esphomatrix1_screen
data:
icon_name: wohnzimmer_temp
text: "{{ states('sensor.wohnzimmer_netatmo_temperature') | round(1) }}"
alias: Wohnzimmer Temperatur
- delay: 5
- service: esphome.esphomatrix1_screen
data:
icon_name: wohnzimmer_hum
text: "{{ states('sensor.wohnzimmer_netatmo_humidity') | round(0) }}%"
alias: Wohnzimmer Luftfeuchtigkeit
- delay: 5
- service: esphome.esphomatrix1_screen
data:
icon_name: wohnzimmer_co2
text: "{{ states('sensor.wohnzimmer_netatmo_co2') | round(0) }}"
alias: Wohnzimmer CO2
# Schlafzimmer
- service: esphome.esphomatrix1_screen
data:
icon_name: schlafzimmer
text: "SCHLAFZIMMER"
- delay: 5
- service: esphome.esphomatrix1_screen
data:
icon_name: schlafzimmer_temp
text: "{{ states('sensor.schlafzimmer_netatmo_temperature') | round(1) }}"
alias: Schlafzimmer Temperatur
- delay: 5
- service: esphome.esphomatrix1_screen
data:
icon_name: schlafzimmer_hum
text: "{{ states('sensor.schlafzimmer_netatmo_humidity') | round(0) }}%"
alias: Schlafzimmer Luftfeuchtigkeit
- delay: 5
- service: esphome.esphomatrix1_screen
data:
icon_name: schlafzimmer_co2
text: "{{ states('sensor.schlafzimmer_netatmo_co2') | round(0) }}"
alias: Schlafzimmer CO2
...
To have the clock screen at a fix position in the loop, I have added my own screen for it; update interval with 1 minute.
The show clock feature of esphomatrix itself is disabled.
It's kind of crazy, but it works - unfortunately, I have to do without the day of the week display.
- alias: Arbeitszimmer - esphomatrix1 - Uhrzeit
description: ''
trigger:
- platform: time_pattern
minutes: "/1"
id: timer
alias: Aktualisiere jede Minute
- platform: state
entity_id:
- binary_sensor.esphomatrix1_status
from: "off"
to: "on"
for:
hours: 0
minutes: 0
seconds: 10
id: connected
condition:
- condition: not
conditions:
- condition: state
entity_id: switch.esphomatrix1_display
state: unavailable
action:
- service: esphome.esphomatrix1_screen
data:
icon_name: external_clock
text: >-
{{ now() | as_timestamp | timestamp_custom("%H:%M") }}
mode: single
I am somehow missing to define a duration (period one screen stays on the display) per screen.
I think it was implemented in the past (screen_t), but removed from actual branch.
I will use it to define e.g. 300s to display the time and 3s for each value in the rooms.
Hi, deutsch ist einfacher...
Das mit der Uhr als Screen ist eine gute Idee, ich denke das kann ich irgendwie umsetzen.
Beschreib mal bitte auf deutsch was du dir vorstellst. Ich prüfe das dann wohlwollend!
Ludger
Hallo Ludger,
ja, auf deutsch ist es vermutlich wirklich einfacher. :-)
Also mit der Uhrzeit als Screen - der über die Sequenz und die Aufrufreihenfolge beim Start erstmal an der ersten Position der "Anzeigeschleife" liegt - klappt das an sich schon sehr gut.
Nachteil ist natürlich dabei die Anzeige eines Icons, das meiner Meinung nach die Zeitanzeige stört - die Anzeige sollte zentriert ohne Icon dargestellt werden.
Es fehlt bei dieser Lösung leider auch die Möglichkeit den Balken mit den Wochentagen einzublenden; diese finde ich irgendwie ganz nett.
Einfach gesagt müsste die Uhrzeit über diesen Weg so darstellbar sein, wie sie auch intern (via show_clock) schon dargestellt wird.
Die Screens sollen in meinem Fall auch unterschiedlich lang angezeigt werden.
Die Uhrzeit z.B. 5 Minuten, danach folgt der "Loopdurchlauf" mit Anzeige der Werte für jeweils 3s.
In der aktuellen Umsetzung kann ich über den HA Service keine Anzeigedauer mehr konfigurieren; laut Beschreibung gab es das wohl mal (Service _screen_t).
Reicht Dir das an Beschreibung oder hast Du an eine ganz andere Rückmeldung/Beschreibung gedacht?
Was mich optisch sonst noch generell "stört", - gerade bei der Anzeige von Zahlenwerten - dass die Anzeige immer linksbündig ist. Hier halte ich eine Konfigurationsmöglichkeit (links, zentriert, rechts) beim Erstellen den Screens für sehr praktisch und einen optischen Gewinn der Anzeige.
Sonderwünsche und weitere Ideen habe ich eigentlich auch noch; aber lass uns erstmal Schritt für Schritt diskutieren.
Ich muss allerdings zugeben; bisher nutze ich parallel noch eine Anzeige mit awtrix software; irgendwie vergleiche ich dort natürlich das Verhalten und würde es mir auch hier wünschen - mal sehen, was tatsächlich (noch) sinnvoll ist.
Vielen Dank für die offene Kommunikation und die Bereitschaft Sonderwünsche umzusetzen. :-)
Grüße
Dirk
Ich habe gerade nochmal mit der Anzeigedauer gespielt und muss meine vorherige Aussage wohl korrigieren:
In der aktuellen Umsetzung kann ich über den HA Service keine Anzeigedauer mehr konfigurieren; laut Beschreibung gab es das wohl mal (Service _screen_t).
Ich bin auf die Bezeichnung "duration" reingefallen.
Ich dachte so spontan das es sich um die Anzeigedauer des Screens handelt; ist ja aber Quatsch -> "lifetime of a screen in minutes"
Ich würde also tatsächlich gerne die Anzeigedauer (show_screen) pro Screen konfigurieren können.
starting with 2023.4.0 there is a parameter show_time for each screen, you can set a longer displaytime per screen.
Please read the "how to update" section in the new README.md before trying!
in 2023.5.0 you will be able to more control the screens, you will be able to disable the clock and to have blank screens in the loop. the pre-alpha version is working more or less, the release will be next month