OK, so now I have to wait until I see the answer to this oneā¦ LOL
Itās about the same as saying:
this car goes 150mph, but this one does 175mph. Which one should we take for a sightseeing drive along the riverbank?
Or to put it another way, relative to the performance requirements of HA which are typically in the ~1s range for a responsive system, either method is significantly faster than that. In theory I would expect sending the info via an HA event to take longer but not significantly so.
1 Like
My thought was that getting the app and having the client push it onto the priority stack would risk having two clients trying to speak at the same time, and cause problems getting to the priority stack. Sending it by event would let HA deal with any type of contention. But then again, thatās a 1/1,000,000 chance of that timing happening I guess.
That and now I know how to send and listen for custom events.
I had hacked together something similar as a bash script awhile back with stream2chromecast and a simple wget command to fetch the TTS (wget -q -U Mozilla -O sonic_temp.mp3 "http://translate.google.com/translate_tts?ie=UTF-8&total=1&idx=0&textlen=32&client=tw-ob&tl=$lang&q=$string"). (variables are populated by the script, but you get the idea)
When I converted it to appdaemon, the output speed was basically identical. I havenāt converted it to the new built in HASS TTS yet, but I have tested it, and it is basically identical as well.
There are (slight) delays in this sort of thing, but I think most of it is in the transmission back and forth to the internet, rather than local processing.
I think you might still have a concurrency issue - AppDaemon is multi-threaded so it is theoretically possible for HA to push out the events so quickly that 2 different worker threads are processing it at the same time. I solved this in my App using a Thread Safe Queue and a single worker thread pulling items off that queue.
Of course as you said, this is a small possibility corner case, but it will tend to become more of a possibility as you add to your system. The early versions of AppDaemon didnāt have any locking and worked fine for a while (I knew I would have to add it eventually but I wanted to see how long I could get away with it). When I added enough complexity and concurrent callbacks in my various Apps, I started getting errors when multiple threads were accessing internal data structures - I added appropriate locking and they were all resolved.
I might need a short refresher on locking and threading. (not today though). Most of my experience has bene on the application side of things with Oracle databases, so Oracle took care of all of that for me. I understand the concept at a high level, but Iāve never had to implement it.
Sure - whenever you are ready we can discuss. The good news is that Python makes it a lot easier than other languages I have done this kind of stuff in!
i had my share of problems with more threads speaking at the same time at first.
thats why i have chosen this route.
-
a worker loop that looks if there is something to speak out or a sound to be played.
-
you can place 10 (or as much as you like) different texts to say or sounds to play in a list with a starttime and a priority added to the sound or text.
-
if there are more things in the list the the loop sorts on priority and time and plays that what is most important until the list is empty again.
-
even if a problem occurs and ha or appdaemon hangs, the list stays there until the app can play the sounds.
Yes, you and I both took the same approach on that. Makes sense since we worked together on it. 
My question was more around contention getting the text to the app from the client so that it can be converted to a MP3 file. Both ways work fine. I was just wondering if there were any pros/cons to each way so I could learn.
i think the biggest difference is that i also made it possible to play sounds in the list.
but i think that its probably the other way around then you say here:
My thought was that getting the app and having the client push it onto the priority stack would risk having two clients trying to speak at the same time, and cause problems getting to the priority stack. Sending it by event would let HA deal with any type of contention
fire 2 HA events within a second and they will both fire your app. so they will speak together.
in my app the loop will only go on AFTER it is finished playing a sound.
in the mean time many other apps can set anything in the list but it wont be played untill the sound that is playing is finished.
i will clean up the app(using the right varnames and getting out testlogs and getting out all kind of other stuff that i use 
) tommorow and upload it
my app had many tests with sounds or texts getting called at the same time. and it has been running for a week (when i wasnt there for 5 days), without errors, now,
i added a lot of features to it since i last posted it.
- it says texts out of appdaemon from each app
- it plays sounds out of appdaemon from each app
- it shuts of radio and starts it again (if radio is on with a boolean and a volume slider)
- setting volume for each sound or text as high or low as you like (so its easy to set important messages louder)
- the hourly clock (with its own volume slider)
- i use an extra app that reads text from a website at random times
- during Christmas i had it play a random song every hour
- it plays a soft sound to my speaker (that has an automatic offswitch when no sound is played for 10 minutes) every 9 minutes.
i will try to make all things optional.
Very cool. Mine just says whatever text I send to it. When I fire an event, the event handler in the speak app, creates the mp3 file and adds it to the priority list. The then part that says it still services it from the priority list like yours does. When I was working on the weather alert some of them were rather long and it just kept on saying them one at a time for about two or three minutes after I stopped testing. So like yours itās not stepping on itself. I like that yours can play music and control radio. Youāve added a lot of nice things to it. Mine talks to Alexa LOL So itās like my house is talking to itself.
i had that for a while too, but then Alexa also on the RPI. so the RPI was takling to itself
be careful, you are getting close to artificial intelligence there.
1 Like
in combination with my STT app (appie) i will get there 
i just need to find the time to work it out.
i already have it like this:
-
i say something to the RPI.
-
the RPI asks me: āi heard you say: ā¦, is that correct?ā
-
if i say yes the RPI saves it under correctly heard text
-
if i say no the RPI saves it under wrongly heard text and asks me if i want to repeat the try.
-
no stops, and yes gives me another try.
-
the saved text can be reused for TTS and for STT. so afterwards the RPI can ask me questions and knows the answer options.
very cool. Iām starting to work on a different aspect of it. Iām going to capture all the events and state changes I do to a database or spreadsheet somewhere. Then run some kind of analytics on it and see if there is anything I can learn about the way we are using our lights that would make the house more intelligent on itās own. Big Data coming to a little Pi near you soon. LOL
2 Likes
Iād love to learn more about this project. I tried this with logentries and Jupyter notebooks when I was doing my laundry room project and both were dead ends for me - more trouble setting them up and trying to figure out how to access the data than actual analysis.
Of course, youāre assuming this is actually Rene youāre talking toā¦
2 Likes
Nope itās him. He never capitalizes his āIā's
2 Likes
its gonna take me a little more time.
i am rewriting the app a little with comments to make it understandable.
but i am also making these settings optional and to be set out of the config:
- radio (if yes, setting for which radiowebpage to be used, radio on/off boolean)
- volume (if yes, volumesliders for radio, clock and speech/sound)
- controle if mainloop is running
- restart boolean
- default speech language
- start delay
- mainloop delay
- clock (if yes, location for soundfiles)
- seperate sound log (if yes, logfile name and location)
2 Likes
It has arrived!
its uploaded to my github (o yes i have a github, so i guess i start to look like a programmer 
)
i have YAML and cfg included and also readme on how to implement things.
its all in 1.
Radio, clock, TTS, volume, musicplaylist, etc.
4 Likes