ycardon / gigaset-elements-proxy

a simple web and MQTT bridge with gigaset-elements APIs (no more maintained)
GNU General Public License v3.0
18 stars 5 forks source link

home assistant mqtt sensor doesn't update #23

Open h4nc opened 4 years ago

h4nc commented 4 years ago

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?

h4nc commented 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?

ycardon commented 4 years ago

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

h4nc commented 4 years ago

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.

ycardon commented 4 years ago

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.

h4nc commented 4 years ago

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.

ycardon commented 4 years ago

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...

h4nc commented 4 years ago

Ok, strange I checked my config and I have allow_unknown_events set to false.

h4nc commented 4 years ago

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.

h4nc commented 4 years ago

I have to reopen this, my automation failed again today. So it seems like it is switching the topics for some reason.

ginkel commented 4 years ago

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
ginkel commented 4 years ago

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?

ycardon commented 4 years ago

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)

h4nc commented 4 years ago

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.

h4nc commented 4 years ago

My automation still doesn’t work because of this issue. Do you have an idea how to fix this?

ginkel commented 4 years ago

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.

ycardon commented 4 years ago

I just had a look on your fixes, I'll be glad to merge !

h4nc commented 4 years ago

I still have this issue. I just randomly get the right state, most times "unknown".

ycardon commented 4 years ago

Hi @ginkel, are you happy with your changes ? If so I'm merging them.

ginkel commented 4 years ago

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).

ycardon commented 4 years ago

Ah ok, I reopen this issue until we find some time to investigate !

h4nc commented 4 years ago

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?

ginkel commented 4 years ago

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).