That wouldn't make sense as stated. In order for the hub to return to the CORRECT mode, it has to have the timezone and location set correctly. With the wrong timezone/location info, it will return to the wrong mode, but it will still return. You can verify this in the mode manager's state variables, as you will see it not only know if you are away or not, it also tracks what mode it thinks it should be in based on the time of day. And the mode is still based on the relative time/location within the HE.
I forced my mode to Day mode today. Then when I left the house, if flipped to Away, and when I returned it went back to Day -- as expected. Here is the event log:
So, apparently, something cause the mode to change from one of the [Day, Evening, Night, Away] as a String object to a mapped object of [locationId:1, name:Day, id:1]. It would seem that by forcing the mode to the value of Day, the mode manager is now working again. I will keep an eye on it and report if I see what is causing the mode to change to an Object. What is odd about this, is that the mode always reported back as "Away", even though mode manager kept reporting the object map for each event.
1 Like
Hey @bravenel, So I can reproduce the issue. When I am away, and return home, it is setting the mode to an object array. Today it happened again. The mode was set to an object array instead of day.
Do you need me to do anything to get this reported as a bug, or do you have what you need
1 Like
I think I know what is going on. Will know more tomorrow.
1 Like
I have been having mode issues as well. A couple times in the last month or two the time has been off causing issues with the mode manager.
More concerning to me has been the mode manager not responding to the change in presence. We use the android Hubitat app for presence. For a while now the mode will stay Away after one of the presence sensors returns. The dashboard will show one or both phones present, but the mode stays in Away mode.
I can't say how the Android app works, but I noticed the iOS app would try to report away, or present state, but if the communication failed, the state would not get received. I think it has to do with switching between wifi direct connect and cellular remote connections. I switched to Life360's free account, as I found it way more reliable since life 360 is always reporting location. The downside is that life360 requires an internet connection. I am sure the app should be easy to fix. I had an app I was working on that was location based, and I solved this type of issue by reporting home/away on a time clock, a geo-fence, and a gps reporting interval of about every ¼ mile, which changed to every mile, and every 10 miles, etc based on proximity to home, and travel speed. I report no more than every 10 seconds, and compute the interval based on max travel speed between last report, and current report and use that speed to compute how long it would take to travel ¼ of the way home as the crow flies. It's not perfect, but it seemed to solve my reporting issue. I plan to implement something like this for another app just for reporting presence without reporting current location to reduce the privacy concerns I have with using life360.
Location within the app is always reported via the cloud. It does not connect directly to your hub on your LAN to report you as "home" because you can set up your Geolocation anywhere you want to. Even if you don't connect to your wifi, the app will still report you as being "home" if your phone is within the geofence you set up in the app on your phone. It does not report your location to the hub.
Possible. I didn’t write the app. I just noticed in WiFi it works 100% and when leaving WiFi it is unreliable. And I thought I remembered it connecting to via LAN not cloud while I was at home. Again, I don’t use it, because it misses presence state changes far too often.
Possible? That's how it works. It does not need to connect to the same network as your hub to report you as "home" vs. "away". It simply reports to you hub when you move into or out of the geofence you define within the app. The app has no information about the location of your hub and the hub has no idea what geofence you have set up in your phone.
That is how Hubitat has described the apps as working. So, while I didn't write the app either, that is what the people who did write it said.
Okay. Great. Share the link to it and go complain elsewhere. What the heck is up with everyone? Just chill out. I have not found anything that claims it is cloud only, and as I stated, I remembered it differently from when I did use it.
Seriously. I reported an issue. No one from Hubitat would respond so I posted here. And my reward is a bunch of attacks asserting I am incompetent in troubleshooting. I find the source of the issue, and a clue as to what may be the source of the bug, which is acknowledged and others comment they too have the problem. I then point out some information that I already stated may not be purely accurate as I dont use the app anymore, and I get attacked for that too.
Go troll elsewhere.
2 Likes
I was merely correcting what is inaccurate information about how the Hubitat phone app works as far as presence goes. That is all.
It’s possible, thanks to your insight, that today’s 2.2.3.135 update at least partially addressed the issue you found. It might be instructive, because you may have a repeatable test case, for you to test again.
- Mode Manager: Fixed null mode display.
I will be testing again tomorrow. I will post my results
1 Like
Today, it worked perfectly.
1 Like
There was another small bug fix in 2.2.3.135. You shouldn't see those object modes anymore.
1 Like
Thank you
1 Like
Can I add a potential “me too” here. Have rolled back to 2.2.2.129 because I noticed with 2.2.3.135:
- the morning mode change from “night” to “home day” at sunrise failed on two days
- HSM did not arm as it should when we have left home.
Nothing else changed other than the upgrade to 2.2.3.135 when mode changes started to fail.
Reverting to 2.2.2.129 saw a return to normal expected function.
2.2.3.145 is working fine for me. I use sunrise/sunset for Day and Evening, and a fixed time for Night. The away mode and return from away are working now since 2.2.3.135, and I know some changes were made to sunrise / sunset computations since 135 release. I would try again, but also, if your mode state appears as an object, force a mode change, then see if the problem returns.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
