Skip to content

Conversation

@RealDeco
Copy link

@RealDeco RealDeco commented Nov 16, 2025

added sensor for phase id's
added text sensors for request & response text
added a virtual touch user button for remote single click

this makes it possible to use another esp to show images for each phase id, show text from respeaker and the virtual button makes it possible to use the touch of remote screen to single click respeaker. (could be expanded to do more than single click)

added sensor for phase id's
added test sensors for request & response text
added a virtual touch user button for remote single click
@formatBCE
Copy link
Owner

Regarding sensors - I honestly think it's pretty niche idea. Truncating text because of max state length can be ok for your case, but not ok for someone else...
See how I send TTS text via event? Probably that would work? You could do it for request too - and use full text in automations, making any adjustments to it on HA side.

@RealDeco
Copy link
Author

here you can see it running:

https://www.facebook.com/share/v/16zmaZoo3T/

and yes the text part could be done both ways, i actually have both ways in my yaml so it's optional which way to use, but sure if you could add event for responses that could be just as good, you only have for tts and ur
it's just much easier to read from another esp device if it's a text sensor...

and trust me, a LOT of people like the screens for their VA's, and clocks 😅

@formatBCE
Copy link
Owner

I understand your use case.
And having something like this absolutely makes sense.

It just doesn't make sense for basic integration config, because it will force users to the way it's done. Reading sensors from another ESPHome device isn't default and common thing, so I will stay on my point that additions like this belong to forks, not to main, basic integration.

I can leave the PR here open, if you want - so others could use your code. :)

@RealDeco
Copy link
Author

problem is having read the events from an automation and place it in a text helper will also truncate to 255..

anyway i understand you don't see the same potential in "outsourcing" the heavy work to another esp, i see it differently, the more i can expose, the more users can customize, and gives no maintenance since it's up the user to use or not (or how) leaving the doors open..🤷🏼‍♂️

about the events, maybe you should add for tts too, thats what most would want to put on the dash, not so much the stt?

@formatBCE
Copy link
Owner

Yeah I guess TTS URI (for playback) isn't enough, having text is needed sometimes.

Regarding truncation - well, you could put it to other ESP with service call, and there you can use whatever symbols count you like. But the core problem isn't truncation itself - but the fact it's done at the source, so basically user cannot decide for themselves what they want to do with full text - because there's no full text anymore.

@RealDeco
Copy link
Author

thats why i use both ways (events and text sensors) 😁 choices, but i will try with service call and events 👍

@RealDeco
Copy link
Author

i like to make things simple so that everyone can play along where most is setup already, then leave entities for those that want to change the default functionality, like swipes for touch, automatically do certain things, but there's a switch to turn that off and do it internally in HA vith automations.

some people put up some cool projects but with a million files and automations and external tools and it just to overwhelming that many people drop even trying it, sadly. make it simple, more will use, make it configurable, even more..

about configurable, surprised there is no switch to turn off the led, omg that light blinds me 😅
and have you found a solution for those that use other mediaplayer, regarding alarms, timers, system sounds..?, i see you use a play_sound script for it all, maybe a event there too would do it? 🤷🏼‍♂️

@formatBCE
Copy link
Owner

I didn't go deep in search of solution to sounds. Again - this is pretty basic implementation, and I don't want to give people more than basic things. For building up on this foundation we have community - you involved :)

LED brightness can be set to minimum. If you want to get rid of it completely - it's pretty easy too, I just never had such a request... :)

Also I keep YAML as close to PE as possible, because it's easier to merge new changes this way.

So - you don't need to convince me that your case is valid and good. You're right. But it's basically narrow path and just one of many, many possibilities that ESPHome giv3s. So I drew the line to avoid making monstrous creature from this YAML. Simple and extendable.

@RealDeco
Copy link
Author

RealDeco commented Nov 16, 2025

brightness! thank you for saving my eyes the torture!, -the reason you never heard that request before is that your device don't have a display, but it do now 😁
i actually dropped light totally for my devices since all devices have display there's no real need for it 🤷🏼‍♂️
those that want to use light can do it from automations and with the phase id's exposed it's easy 👍

@RealDeco
Copy link
Author

i got it working using the events instead of text sensors, but seems like we are still being truncated to 500

did some troubleshooting and after adding this to the yaml just before the event is sent:

      - lambda: |-
          ESP_LOGI("tts_debug_src", "TTS x length = %d", (int) x.size());
      - script.execute:
          id: send_tts_text_event
          tts_text: !lambda 'return x;'

i get this:

[06:41:28][D][voice_assistant:764]: Assist Pipeline ended
[06:41:28][I][tts_debug_src:1602]: TTS x length = 500

seems like the text is already truncated when we get it from the pipeline 🤷🏼‍♂️

@formatBCE
Copy link
Owner

Well that was inevitable...

@RealDeco
Copy link
Author

i would call it surprisingly unexpected :(

@formatBCE
Copy link
Owner

i would call it surprisingly unexpected :(
But why?

Any network protocol would restrict max data length.
It's even more true for microcontrollers. Imagine that someone would send a million-char string to ESP device.

@RealDeco
Copy link
Author

i don't think it's a network restriction but tested some more and can send longer text from developer tools to the recieving device, so thats not where it's truncated along the way, so i need to find the text before the espdevice gets it, i guess..🤷🏼‍♂️

then again, i didn't think much about the full lengt and that some people might want that for something? (go to debug menu and get it?) but since you mentioned it i kinda got obsessed with doing it 😅 500 characters is just fine (and safe) for small displays and wall dashboards 🤷🏼‍♂️

sidenote to the "and safe", around 788 characters, above that the display crashes, i believe LVGL and memory, without showing the text (still recieving it) i can send more.. so yeah 500 is safer 👀

@formatBCE
Copy link
Owner

Yeah I guess hardware will limit somewhere there, but I'm surprised that 500 symbols limit is introduced somewhere early.

@RealDeco
Copy link
Author

removed text sensors and only using events now, added node name to events as it's much easier to read than device id (no need to search for id)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants