Yup. I was hoping to use the Amazon Echo devices as a general TTS speaker.
I have never attempted to use Home Assistant for TTS on an Amazon Echo device.
Currently, this integration does not support any sort of TTS device mirroring between HA and HE.
Mine never close. (still on 1.11 though). While developing I noticed that on receiving a defective request, HA would simply close the connection without giving any error. Originally I did not want to reconnect on closing so I can figure out what I did wrong.
Reconnecting on closing is probably a good idea now but it would be interesting to investigate what makes it close.
@SmartHomePrimer what happend just before that closure?
1 Like
I looked (very) briefly at the HA websocket code: core/homeassistant/components/websocket_api at dev · home-assistant/core · GitHub
Can you recall what the issues were with a message that caused the connection to close? They seem to have fairly robust exception handling that would try to send an error response instead of just crashing the connection on the server side.
I do see some Disconnect handling, but mostly in relation to auth issues at startup and not after a long period of uptime.
@SmartHomePrimer, do you see any other anomalous behavior within HE or elsewhere on your network in the same timeframe as the disconnect/reconnect on this driver?
Basically it was a malform JSON request. I can't remember the specifics. Name of the variable instead of its value I think.
1 Like
Still alive today, but I’m not being a very good tester. 
I had disable the debug logs (habit). It’s closing and reconnecting a lot.
I turned the logs on again and I’ll monitor for errors.
That seems like a lot. I suspect something is failing unexpectedly on the HA side, like @ymerj was discussing from earlier in his testing.
Is there a log of any sort on the HA side? If not, we may want to add more logging to the traffic going out from HE to try to figure out what might be at issue.
There is error handling in the websocket api. You would just have to catch it if there is a response generated from the interfaces.webSocket.sendMessage command. 
My best guess anyway..not really that familiar with configuring websockets.
It's at the very end of the page below:
I have an updated version of the Parent Driver, where I incorporated the webSocket reconnect logic from my Harmony Hub driver. I am testing it now. If any of you would like a copy of it, just let me know and I’ll PM you. I’d prefer to not just update GitHub with this new version until I have some runtime on it, although the Harmony Hub Driver does seem to do a good job of always staying connected.
4 Likes
Good point. @SmartHomePrimer, if you turn logging back on we should be able to see whether there's a response on the socket with the error info before it is closed (presumably by the server).
For some quick and dirty error reporting, you can add the following line in the parse method:
if (response.type == "result" && response.success == false) log.error "HA reported error: ${response.error?.message}"
It should now look similar to this:
def parse(String description) {
if (logEnable) log.debug("parse(): description = ${description}")
def response = null;
try{
response = new groovy.json.JsonSlurper().parseText(description)
if (response.type == "result" && response.success == false) log.error "HA reported error: ${response.error?.message}"
if (response.type != "event") return
def newVals = []I installed version 0.1.15 and the initializing went into a loop. I put back 0.1.11 and it is fine.
That may be what @SmartHomePrimer was running into, @ymerj. I reverted my changes (made 0.1.16 version to avoid confusion), pending further investigation.
Ok. Left it at 0.1.15 and finally got an error
Removed the image because I’m a dummy and posted an error from another device 
Although, it sure does keep that websocket open! 
But I’m thinking this probably isn’t a good way to do it.
@ogiewon Please PM me the version that uses the method from the Harmony integration. I’d like to try that next. I’ve been using that for a long time now and that definitely does the job to keep the connection open.
PM sent.
1 Like
Since I was using it for the entire week without suffering any disconnection, it appears that HA is not subject to random nor scheduled disconnections. Automatic reconnection just hide the problem.
1 Like
When I recently took a look at my system (not being used for production, just development and testing), I noticed that the webSocket had been closed about 3 days ago. This may have been while I was upgrading Home Assistant on my RPi4 last week, or possibly caused by me changing firmware on my UniFi network switches... 
I never thought to verify that this new Hubitat integration was still working afterwards until I saw @SmartHomePrimer's post yesterday. Thus, I decided to look at the webSocket reconnect logic, and give the version from my Harmony hub a try to see if it was more resilient to various types of outages. I did notice during testing this evening that restarting Home Assisant, does result in a 'closing' webSocket status being received. My Harmony reconnect logic also increases the amount of time between each reconnect attempt, to not hammer on the HA system.
Here is an example of what I see when I restart HA on the RPi. You can see my reconnect logic retries to connect at increasing intervals (max would be 600 seconds.)
I guess I wasn't looking at the other end. A situation like the one you describe is bound to happen to everybody as well as other scenario whitch are not cause by this driver.
I look forward to use your improve reconnect logic.
1 Like
I spent some googling, and there is various chatter about disconnections. Most of them seemed to be hass.io-based, but there were no obvious smoking guns.
Some theories I saw: faulty storage, faulty wifi hardware, wifi hardware going to sleep (power saving), SMTP server mis-configured, memory leak necessitating system reboot.
@SmartHomePrimer, since yours seems pretty reproducible, I'd suggest that we try to sniff any of these out. Can you access a log on your router to see if your client is disconnecting/reconnecting around the time of the failures? Can you check uptime on the system or container that is running HA?
I do hope it is an improvement. 
I have pushed v0.1.17 with my reconnect logic changes. Not all that different from @tomw's changes, I believe. Seems to be working fin for my HA to HE integration. Hopefully others can test it as well.
1 Like
