Open h4nc opened 4 years ago
My former topic for this state was
MyHome/
With MQTTExplorer I noticed that the states home, night,...
is now in
undefined
Do you know why?
Hi,
At first, I was thinking about a change in the gigaset json format... but it looks the same.
By looking at the code (it has been a while I havent touched it), you should see something in the log https://github.com/ycardon/gigaset-elements-proxy/blob/0277627505a86e55f40cf2ad2e4675b33c4b91c8/src/mqtt.ts#L104
Then, an event named gigaset/<basename>
is sent with the same value
https://github.com/ycardon/gigaset-elements-proxy/blob/0277627505a86e55f40cf2ad2e4675b33c4b91c8/src/mqtt.ts#L105
I checked my basestation name in the App and it is still the same as before.
When I delete all the entities in my MQTT broker regarding Gigaset, the Proxy will open the topic with the basestation name again but also one with „undefined“. I can only see the mode changes in that undefined topic. I changed my ha automation to that topic and it works. Strange though that it suddenly changed without me doing anything.
There are two modes for reading the intrusion settings:
[edit] I don't see the second point in the code... we might have speak about it but never implemented it
So it might be the "change intrusion settings mode" event structure that has changed.
And that would be the reason why it opens that undefined topic? Could you check if you also get this? As before I’m always glad to test things, but ad before I can’t help with the code.
Well, if you have the allow_unknown_events
config set to true, every event will be pushed to mqtt, including the ones that doesn't have a friendly name (even.o.friendly_name
), resulting in pushing mqtt messages to the topic gigaset/undefined
...
Ok, strange I checked my config and I have allow_unknown_events set to false.
I noticed that my automation did not work again. Without doing anything I get the right state in the old topic again. So I changed back my automation.
Still strange that it used that undefined topic for a few days. Hope it stays like this.
I have to reopen this, my automation failed again today. So it seems like it is switching the topics for some reason.
I am also seeing this:
[Wed Feb 05 2020 17:24:26] [LOG] acquired event: {"id":"<redacted>","state":"ok","ts":"1580923463878","type":"isl01.bs01.intrusion_mode_loaded","o":{"basestationId":"<redacted>","configurationLoadedId":"<redacted>","modeBefore":"night","modeAfter":"home","userId":"https://im.gigaset-elements.de/identity/api/v1/openid/identifier/id/<redacted>"},"source_id":"app-services-intrusion-detector@dkrd3.reef","source_type":"isl01","state_pre":"ok"}
[Wed Feb 05 2020 17:24:26] [LOG] event sent as mqtt_topic: gigaset/undefined, value: home
After having had a look at the event it became clear that the cause of this issue is that the API is no longer submitting the friendlyName with the event. The hex baseStationId is still provided, so I'm considering using that instead. This would be an incompatible change, though.
@ycardon Any thoughts?
No strong opinions, I'm not using this feature :)
I can make the change but I don't have access to my Gigaset instance: could you post me a sample event and point me the field that will be used as the basestation friendly-name replacement ? (maybe we can also use a prefix like basestation_
to make it clearer)
This is what I goto in the logs when I changed from home to away:
[LOG] acquired event: {"id":"ID1","state":"ok","ts":"TS1","type":"isl01.configuration_changed.user.intrusion_mode","o":{"modeBefore":"home","modeAfter":"away"},"source_id":"app-services-intrusion-detector@****.reef","source_type":"isl01","state_pre":"ok"}
[LOG] event dropped: unhandled event type: undefined
[LOG] acquired event: {"id":"ID2","state":"ok","ts":"TS2","type":"isl01.bs01.intrusion_mode_loaded","o":{"basestationId":"BASEID","configurationLoadedId":"ID3","modeBefore":"home","modeAfter":"away","userId":"https://im.gigaset-elements.de/identity/api/v1/openid/identifier/id/ID4"},"source_id":"app-services-intrusion-detector@****.reef","source_type":"isl01","state_pre":"ok"}
[LOG] event sent as mqtt_topic: gigaset/undefined, value: away
Would be great if that helps to fix it somehow.
Note: I have allow_unknown_events set to false.
My automation still doesn’t work because of this issue. Do you have an idea how to fix this?
The version in my fork at https://github.com/ginkel/gigaset-elements-proxy seems to work for now. There is still some cleanup I'd like to perform before opening a MR, though.
I just had a look on your fixes, I'll be glad to merge !
I still have this issue. I just randomly get the right state, most times "unknown".
Hi @ginkel, are you happy with your changes ? If so I'm merging them.
Thanks for merging my changes and sorry for not getting back to you earlier, @ycardon! There is one thing that's currently still broken, which prevented me from opening a PR: I used to do a refresh when starting Home Assistant via /force-refresh
, which still seems to be broken (I didn't investigate yet, but HA does not have the intrusion mode until it is changed after a restart).
Ah ok, I reopen this issue until we find some time to investigate !
Ah ok, I reopen this issue until we find some time to investigate !
Would be great if you find time. I'm still on 1.3 because of the issue @ginkel mentioned above (force refresh) and one of my automations doesn't work because the state isn't reliable any more.
Offtopic: @ycardon I don't want to open an issue for that. Because of another issue (not related with the gigaset proxy) I had to restore HA to a backup several times lately. I noticed something odd. After a restore the gigaset proxy didn't show up in the supervisor section in most cases. I have several addons and only two addons had this (gigaset and unifi). After rebooting the pi (supervisor - system - Host System reboot) the missing addons show up again. Do you have an explanation for this? Also restores sometimes take about 25 minutes and sometimes up 60 (or even more). Any idea why it differs so much?
I have an experimental fix in https://github.com/ginkel/gigaset-elements-proxy, but I don't see why it's not working (the code in line 106 does not seem to get executed https://github.com/ginkel/gigaset-elements-proxy/commit/52a32e52e35a7b09563c2f8bb650da4e3c192438#diff-70fba6368d3fcd389b435446e2177ea0R106).
Lately I'm facing some issues. All worked fine before for months.
1) within the gigabit app I have a rule that automatically enables home at a certain time. I have an home assistant automation that triggers 5 minutes later and fires a message if the rule failed. Something like "Gigaset still in night mode". The thing is the app does change the mode and I can also see current mode in "basestations". It seems like there some issue with mqtt (mind that all other things using mqtt work fine).
I don't see anything strange in the logs.
Edit: When I hit "Force refresh" the sensor updates correctly.
2) This may be not related but it also happened in the last days, so maybe good to mention it. I had some false alarms. The mode was set to home but I got an intrusion alarm nevertheless (already in contact with the support on that). They told me a big DNS Server had issues and that's the reason for this. Did you also face issues lately?