right, this is a known issue which is sorted in 2.0.7, in the mean time the only way to clear this out is to remove the device in the cast integration, then re-add it.
So, lets give that a go, then see if that makes things a bit more stable.
3 Likes
That seems to have gotten rid of that error.
3 Likes
I've gotten it to clear by pushing various things through the interface for the affected device, but it's not consistent.
What I think needs to happen with this app is to fire and forget TTS actions. If the GH device doesn't play it, there's no point in caching it like the HE does (and can often be heard dumping when the jam is cleared).
Not following this...
What I mean is that TTS messages are getting cached, showing up in the uriQ, and when that happens I am sometimes able to get everything pushed through via the device screen without having to remove and re-add the device.
I assume it is the HE that is caching those messages, not the GH, right? I can't think of any reason for the caching to be happening, and when it does dump this way, my GH device can spend several minutes reading every one of them off.
Having a play Q for the messages was a community request.
1 Like
The reason for the community request for caching is that if you cast multiple messages to a device the messages get truncated by the next message if it's not done playing the previous.
The problem you are experiencing is that HE randomly loses sync with the chromecast devices which results in errors in the logging and the messages get backed up in the queue since they cannot be played when this happens. There are a couple of things you can do to help with this, but even then it's possible that this can happen on occasion.
-
Make sure you assign static ips to every chromecast device (DHCP reservation) so that their ip is always the same.
-
Create an RM rule that sends an initialize command to the chromecast devices occasionally to make sure they stay in sync, this will also clear the queue if there are messages "backed up" so they don't play all at once as you have experienced.
Here is an example of how to do the initialize step:
The periodic triggered rule (I do it every 3 hours YMMV doing it too frequently will likely cause messages to get truncated or lost if one is playing during this action)
The custom action detail:
With these two steps, I have pretty much eliminated the problem. The chromecast integration is BETA (@chuck.schwer mentioned he thought even more like ALPHA) as a result it's not perfect. @mike.maxwell stated that this was a "quick" implementation and that more time would be spent improving later.
3 Likes
Thank you. I will try this.
I really do use it for quite a few things, and so far it has been more reliable for me than cast-web-api and depending upon a local PC server.
I've never experienced anything similar to this, but this morning my hub "froze". Until now the hub was responsive, had no stability issues, but it seems something started to go wrong.
The hub wasn't actually frozen, it responded to ping requests, but its web server wasn't responding (timeout), and the automations were not working. After a reboot (power cycle) everything was working again.
At 6PM (when I got home) I noticed that the hub was extremely slow. It took 10-20 seconds to get any kind of response from its web interface... so I rebooted again. And it was working fine.
And now (11 PM)... it started to slow down again. Everything takes "ages" to complete (so far it was instantenous). Here is the log from a button activated scene (three, actually):
It seems there is a ~4 seconds delay somewhere, and it can be experienced everywhere, even on the web interface.
Nothing has changed since yesterday... I don't use TTS, I have no Google Home, no integration with other hubs... All I have is a (hardware) dashboard running 24/7, a telnet socket to my NUT server, and 2 speakers (the driver uses HTTP to communicate with them), but nothing else special. I have a simple Zigbee-only network and I use built-in apps (+ influxdb logger).
@mike.maxwell do you have any idea where that 4 seconds may come from? My suspect was DNS, but a local-only hub doesn't use my DNS server to execute automations... So I have no ideas where to start right now,,,
fw 2.1.0.123
This app is on the bad list. I had frequent lockups and I believe this app contributed heavily to my instability. Everyone's experience is different but I would recommend disabling (you don't need to remove it) and see how your hub responds after a reboot.
Also be careful with any 3rd party driver's/apps that communicate on the LAN. Nothing confirmed, but there have been rumblings of issues with LAN devices especially when they do not respond in a timely fashion.
1 Like
As @stephack says, http CAN be a problem depending on the method used by the driver. Sync or Async. Async doesn't "wait" while the other end responds. Sync, which is easier to write, waits for the other end to respond. Any slowdown in it's response is directly added to the driver's response.
On the other hand, influxDB would be the very first thing I'd disable.
3 Likes
Thank you guys, I removed influxdblogger, rebooted, and now everything seems to be just fine... but it's normal, a reboot always solved the issues for a few hours.
Next one will be the speakers's driver in case anything goes wrong.
I have no idea why it worked for me for months, but... whatever, we'll see.
Actually everyone was suggesting you disable not remove. And yes, reboot can temporarily clear up issues. So just disable next time you have an issue. That will make troubleshooting a lot simpler.
I assume sync and async is really at the app side of things, not the driver? For instance I have a few drivers that collect data via HTTP like this:
sendHubCommand(new hubitat.device.HubAction(
method: "GET",
path: "/query/device-info",
headers: [ HOST: "${deviceIp}:8060" ]
))
Or is there a way to do those async, too? Sorry if it is a stupid question - LAN apps/drivers are not my specialty...
Edit: I guess if this is correct, then my example would already be async... (?).
A driver example might look like:
def params = [ uri: "https://api.apixu.com/v1/forecast.json?key=$apixuKey&q=$zipCode&days=3" ] try { httpGet(params) { resp -> if (resp?.data) obs << resp.data; else log.error "http call for ApiXU weather api did not return data: $resp"; } } catch (e) { log.error "http call failed for ApiXU weather api: $e" } //if (debugOutput) log.debug "$obs"
for Sync(hronous)
Async would snap that in half and look similar to:
private getXUdata() { def obs = [:] def requestParams = [ uri: "https://api.apixu.com/v1/forecast.json?key=$apixuKey&q=$zipCode&days=3" ] asynchttpGet("asyncHTTPHandler", requestParams) } def asyncHTTPHandler(resp, data) { if(resp.getStatus() == 200 || resp.getStatus() == 207) { //log.debug "$resp.data" return parseJson(resp.data) } else ...
Yes, but you can also use hubaction commands for that instead of httpget or asynchttpget... Thus my confusion.
I'll go read some more on the difference between the two ways of doing it. I've been flipping through the ST docs on it, but I haven't seen anything conclusive in the sync vs async behavior of hubaction yet.
Sorry, misunderstood the question. 
Nah, I didn't express my question right - typical for me. Thanks for the concise example though!
I have a project that will need a new lan driver that I've been avoiding, as I don't know what I don't know on those. Guess I just need to dig in. 
EDIT: The Hubitat guys were nice enough to confirm that Hubaction is async (which it looked like it was based on how it works, but it is always nice to confirm). So that's good news for me since a few custom drivers I'm using did it that way.
1 Like
Well, slowdown is back. More cleanup... 
Er... how can I disable a certain device or app? It must be well hidden somewhere 
It is well hidden 
On the Apps page, in the upper right corner is a well hidden (dim grey) X. Click it and it turns bright red and an extra column appears left of every App. Click any box there to disable that app.
1 Like
