You'll have an issue once the device or whatever it's doing requires a refresh command to work properly.
I don't use Chromecast, but I do use refresh(). I'm not seeing this.
1 Like
That is part of my initialization on ALL my chromecast speakers. I have had the error twice about 12 hours ago. I have had several announcements since then that worked. It is actually more reliable for me on .132 than previous updates. So, it is not "fully broken". I do see the errors. But that is not enough for me to roll back though.
Works fine on .130, broken entirely on .132. Seems you may be doing something different than the standard integration if yours is working properly. Out-of-the-box, it does not work on .132.
Weird, refresh even for a firmware upgrade of a Zigbee switch gives the same java error in the logs. Must be how it's calling the function then. It is 100% breaking more than just chrome cast integration.
I am running a rule that initializes and refreshes every 3 hours on my out of box chromecast integration beta. NOT fully broken on .132. I have always run this because all my TTS devices have had issues staying connected.
1 Like
If you have a custom rule then it's no longer out-of-the-box anymore.
By default on .132 it does not function and needs fixed. Why argue? It's clearly a problem.
You said it wasn't working if you used refresh. I just showed you that it was.
2 Likes
No, I said it may be the way they're calling the refresh function. Developer's of other pieces of Hubitat's add-on's such as a device driver may call that function the same way and it will result in the same error and loss of functionality. So yes, it is indeed broken. The default use of chrome cast integration does NOT work out-of-the-box on this version but did work in the previous release, this means it is indeed broken. Instead of arguing semantic's, let's try to fix the problem.
I’m sure that Hubitat’s staff will look into it, but it seems to be far less a wide-spread problem and more an isolated one.
2 Likes
It seems anyone running this newer release with default settings will fail to be able to use chrome cast and possibly anything else that calls that function the same way. (The possibilities are technically endless depending on the developers). So yes it may be isolated or it may be wide-spread. Either way, it's not right in its current state. I don't want the issue to be dismissed and ignored for the next 'x' amount of updates going forward... it should be addressed in the next version and this version (.132) should be pulled.
You don’t pull an entire release because one integration isn’t working part of the time. If it is key to your installation then you have the choice to roll back to .130.
4 Likes
People were having that same issue prior to the .132 release (hence the rule I am running as well as the community chromecast helper app that you can add).
When it comes to programming semantics, aka syntax matters a great deal. Not sure you quite understand how the commands work. Anyone who calls the refresh command calls it by using the same verbage: "refresh()". So, there is not much way that the way they are calling it out would be different from one app to the other.
I am not arguing the semantics. I am arguing the overly dramatic fully broken comment that is not quite true. As @thebearmay stated, it is not something to pull an update for and it may not be as widespread as you feel that it is. Does it suck when it doesn't work? Absolutely. That is why I wrote the rule to initialize and refresh..... long before .132. Am I watching this feed to see if something addresses my need to run that rule???? Again... ABSOLUTELY.
1 Like
No they were not. And even if they were, it wasn't caused by the same code as this. Refresh() is not how it's called nor is it what is actually going on in the backend. I'm talking about the function itself and how it is written, not the code you see on the hubitat UI.
Being that out-of-the-box this integration does not work, it is indeed FULLY broken. It should work out-of-the-box. Before continuing to argue, know that I already am aware of the exact line of code where the problem is and the faulting code / how to fix it. It is indeed a line of code where it looks like someone was trying to "tune" it for some reason, and caused a buffer overflow, but hey what do I know?
If a release has a broken component then yes it should be pulled or at the very least it should be patched in the next release.
It either works or it doesn't. If it requires adding special rules to make something work that used to just work - it's indeed fully broken.
It's insane that we are even arguing this at all. This forum is toxic just like the HA forums.
1 Like
What doesn't work out of the box? The Chromecast integration (which I'm not questioning), or refresh? Because refresh() does work for several of us.
The Chromecast integration is labeled as beta for a reason. Caveat emptor.
1 Like
I'm not talking about using the refresh command from the hubitat UI. I'm talking about using it on the backend. For example, calling the function from a device driver. Refresh() is not the actual function's code - it just calls to action against the actual code.
Yes, I can agree with the beta flag for sure - you got me there, however, if it works in a previous release it should work in the next release. I know not everyone is perfect and people make mistakes, but I'm just asking to have it fixed. It's weird that people here are arguing that it's acceptable to keep this broken code in future releases.
P.S. I ended up fixing it myself within 5 minutes. It is indeed a coding problem. 
1 Like
That is what I am talking about. I make use of it in my sole zigbee driver.
How are you loading up the javascript? Are you just calling "Refresh()"? Because that's not what I'm talking about...
Using schedule(). How are you doing it?
For the faulting zigbee driver I mentioned above (not made by me), it was importing the java library and using a custom refresh command made by the developer. It was 109 lines long. It made use of the refresh() but only while determining variables that it was checking first. The faulting line required ''s around the variable. Prior to this update it did not.
P.S. My posts were never meant to sound impatient. I'm very patient and willing to wait for a fix. It just came across to me like people on here were refusing to see it was actually a problem and dismissing it as if it wasn't important. It's probably important to someone. 
1 Like
