I use the botched drivers and haven’t seen any errors with them. I have a combination of iris V2 contact sensors, centralite and Hue motion sensors, zigbee bulbs, and 11 ge/jasco zwave plus dimmers and switches. I would disable the echo speaks app and all drivers and see if the problem is resolved. There is a new echo speaks app in beta that is attempting to address the issues with it. I had slowdowns across zigbee, zwave, and the web ui to the point of needing to reboot every other day before I started using the beta. My hub was immediately more responsive after installing it.
Speaking of things being challenging, are there any plans to make the logs that support has access to available to end users? It sure would be helpful if I could correlate the logs I see with the logs you all see to track down what is throwing errors on the HubAction process. I realize you all don’t want folks to have access to the device, but something like a setting for remote syslogging of the OS/Hubitat process logs would save lots of back and forth. I’m resorting to putting my hubitat on a span port to sniff traffic, then asking support for the logs of when my errors are occurring and trying to look through captures. As things are today, I’m with most of the folks above and have to reboot every 8-10 days.
search for "syslog" -- it's been covered repeatedly.
Synopsis: All logs visible to Support have been duplicated to the logs we can see. When they find one that isn't, they add it to the next build.
Exactly that happened, and for a day or two, people were seeing errors that didn't exist prior. "Sky is falling... oh, never mind" LOL
ws://[hub ip]/logsocket is also available.
No. These are not what you seem to think they are, and would not be of help in what you are trying to track down. As @csteele points out, every error that IS relevant gets posted to Logs -- and if/when we find an error that doesn't routinely get reported to Logs, that gets fixed. There are some errors that can happen in communication protocols that don't show up in any log, and aren't directly identifiable, just an unfortunate artifact of the code in use. For these, even we use embedded log.debug in the code to track them down.
I know I was a little surprised when support told me about echo speaks throwing an error about once per second. Those errors didn't show up in my log at all. I had disabled Echo Speaks, but not the echo devices. Once I got rid of the devices my hub speed has been fine ever since. But I never saw the errors.
I’m already doing this; I wouldn’t have said anything if I hadn’t already been doing this. There are logs that they have access to that I’m not getting through logsocket.
Line 5304: 2019-08-20 01:05:45.147 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5305: 2019-08-20 02:45:30.651 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5306: 2019-08-20 05:15:17.483 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5307: 2019-08-20 06:40:04.729 [zwProcessPool-thread-02] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5320: 2019-08-20 09:24:12.825 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5321: 2019-08-20 10:34:08.580 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5323: 2019-08-20 13:31:22.029 [zwProcessPool-thread-02] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5324: 2019-08-20 14:26:30.890 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5395: 2019-08-20 17:37:58.751 [zwProcessPool-thread-02] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5396: 2019-08-20 18:19:01.992 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5694: 2019-08-20 21:45:23.523 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5695: 2019-08-20 22:11:53.716 [zwProcessPool-thread-02] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5696: 2019-08-21 01:53:46.594 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5697: 2019-08-21 02:05:27.714 [zwProcessPool-thread-02] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5704: 2019-08-21 05:59:32.307 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
Line 5705: 2019-08-21 06:02:50.268 [zwProcessPool-thread-01] WARN com.hubitat.hub.service.LanService - Unknown HubAction: 8408
So my next question is does 2.1.4 now include these logs because I didn’t see anything about it in the release notes @bravenel
I'm kinda glad to know that I'm not the only one who experiencing this hub "slow down effect" also.
After I reboot my hub I notice for each room that has a light bulb or light switch associated to a motion sensor or a contact sensor (via RM or SL), the light turns on less than a second every time you walk into that room or open the door, which is great!
But come 5 to 7 days later, each room will have a 4 to 6 second delay (very rarely not come on at all) before turning on. Which means I have to reboot the hub again.
I have tried numerous times to do a Z-Wave Network Repair, as well as powering down the hub for 30 minutes for Zigbee mesh heal. Hoping that would fix my delay issue, but really never has.
1 Like
OK, time to report in
I switched my GE switches back to Generic drivers, deleted everything Alexa Speaks and also dropped L360.... and
Prior to this, Z-Wave repair took 2.5 hours (~30 devices), today 9 mins
The GE outlet that generally takes 2-5 seconds and took 28 seconds to turn on last week, has been taking less than a second everytime. Even my wife mentioned how much faster it is
Now to get an updated Echo Speaks app and see if we are still in business 
Rick
Do you mean Echo Speaks or Alexa TTS?
Sorry, Echo Speaks
Rick
No, a ticket just got opened 6 days ago to get this error message added to the user logs. As Bruce pointed out, if we find a log that is not being logged to the user log then it gets added.
The new Echo Speaks v3.0 beta is available here: GitHub - tonesto7/echo-speaks at beta .
I've tracked down a ton of bugs and I'm working on one for cookie refreshes failing and silently clearing the authentication. There are still items remaining but it's pretty stable
4 Likes
Can we just replace the v2 app code with v3? Or does it need to be reinstalled? Thanks
EDIT: I was too impatient and went ahead and updated the code, it does seem to work but when I click on the button for login status, I get this error: Error: Cannot cast object 'null' with class 'java.lang.String' to class 'java.lang.Integer'
EDIT: after installing, I’ve noticed my hub is very slow to respond to actions/events... looks like I’ll be rolling back for now ..
Did you update the driver software as well? Also I would open the app and click through and then hit done if you haven’t.
Also, there is a new app. The echo actions app needs installed as a separate app.
And... if you followed the instructions and used the embedded links to GitHub... you are still on the old version. The docs need updating
I IM'd @tonesto7 the other day re: the new echo actions app but no response so far, however I do have it installed
Everything seems to be working fine
Rick
Good to hear. The latest version is now on his GitHub under the beta channel for echo speaks.
1 Like
I've installed the most recent release and as soon as I created a couple of actions my HUB started to slow down and many of my unrelated RM4 rules became unresponsive. I disabled all eco speaks apps and devices and the hub is back to working order.
Any advice?
Contact @tonesto7. Under the app I believe there is an option to send logs and diagnostic info to the author.
I made the decision last night to rewrite the web request system.
So I’m going to do that today and push out the update tonight or tomorrow.
