Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

home assistant mqtt sensor doesn't update #23

Open
h4nc opened this issue Jan 31, 2020 · 22 comments
Open

home assistant mqtt sensor doesn't update #23

h4nc opened this issue Jan 31, 2020 · 22 comments
Assignees

Comments

@h4nc
Copy link

h4nc commented Jan 31, 2020

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 already restarted the gigaset addon in home assistant (formally known as hassio).
  • Restartet mosqutitto broker

I don't see anything strange in the logs.

Edit: When I hit "Force refresh" the sensor updates correctly.

  1. 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
Copy link
Author

h4nc commented Jan 31, 2020

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
Copy link
Owner

ycardon commented Feb 2, 2020

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

console.log(`sending actual alarm mode: ${base.friendly_name} | ${base.intrusion_settings.active_mode}`)

Then, an event named gigaset/<basename> is sent with the same value

mqttClient.publish(`gigaset/${base.friendly_name}`, base.intrusion_settings.active_mode)

@h4nc
Copy link
Author

h4nc commented Feb 2, 2020

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
Copy link
Owner

ycardon commented Feb 2, 2020

There are two modes for reading the intrusion settings:

  • when the proxy starts, it reads the intrusion settings via the gigaset states (same message you can read on /basestations)
  • when the intrusion settings are changed by the user, it reads it from the corresponding event.

[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
Copy link
Author

h4nc commented Feb 2, 2020

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
Copy link
Owner

ycardon commented Feb 2, 2020

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
Copy link
Author

h4nc commented Feb 2, 2020

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

@h4nc
Copy link
Author

h4nc commented Feb 3, 2020

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 h4nc closed this as completed Feb 3, 2020
@h4nc
Copy link
Author

h4nc commented Feb 4, 2020

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

@h4nc h4nc reopened this Feb 4, 2020
@ginkel
Copy link
Contributor

ginkel commented Feb 5, 2020

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
Copy link
Contributor

ginkel commented Feb 9, 2020

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
Copy link
Owner

ycardon commented Feb 10, 2020

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
Copy link
Author

h4nc commented Feb 13, 2020

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
Copy link
Author

h4nc commented Feb 28, 2020

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

@ginkel
Copy link
Contributor

ginkel commented Mar 2, 2020

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
Copy link
Owner

ycardon commented Mar 2, 2020

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

@h4nc
Copy link
Author

h4nc commented Mar 25, 2020

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

@ycardon
Copy link
Owner

ycardon commented Apr 14, 2020

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

ycardon added a commit that referenced this issue Apr 14, 2020
@ginkel
Copy link
Contributor

ginkel commented Apr 17, 2020

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
Copy link
Owner

ycardon commented Apr 17, 2020

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

@ycardon ycardon reopened this Apr 17, 2020
@ycardon ycardon added the bug label Apr 17, 2020
@h4nc
Copy link
Author

h4nc commented Apr 29, 2020

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
Copy link
Contributor

ginkel commented Apr 29, 2020

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 ginkel@52a32e5#diff-70fba6368d3fcd389b435446e2177ea0R106).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants