search

LordMike / MBW.BlueRiiot2MQTT

Utility to map between Blue Riiots pool API, and Home Assistant MQTT
47 stars 2 forks source link

Phone App locked after setting pump schedule #47

Closed kryzpee closed 3 years ago

kryzpee commented 3 years ago

Hey Mike,

thanks for your great work. The service worked well until today. As I rewrote my automation for the pool pump to a dynamic trigger based on the available energy form my PV, I wanted to set the pump schedule accordingly. After publishing a (test) schedule [["06:00", "12:00"],["18:00", "22:00"]] to "set_pump_schedule" I can't access my Blue account with the official Android app anymore. After logging in it just shows a blue screen with "Failed to load data" and Retry/Logout buttons.

Would appreciate your help.

Cheers, Kryz

kryzpee commented 3 years ago

Further observations:

LordMike commented 3 years ago

Woops - missed this one.

Wow, that is odd.. This is always a risk when messing with API's.. (sidenote: The last schedule you posted is invalid, it's missing a ] - I'm guessing thats a typo)

Try sending none or manual, instead of the schedule string you've sent. It should clear out the schedule - assuming the schedule is the issue.. :O

kryzpee commented 3 years ago

You are right, the missing ] is a typo here. Actually I just try it with one schedule. Already did that both with normal and none yesterday and since then it's stuck on manual and I only have one reading a day. So I send the schedule, the topic goes to "Scheduled" with the correct schedule as attribute and after the next sync it's going back to "Manual". But the app is still not usable.

I think I can create a new account but I am afraid that it will be locked too after I'll try setting the schedule then.

LordMike commented 3 years ago

The new account will likely get the same issue. It's possible Blue Riiot changed something on their end.. a value I'm not sending back.. :/

LordMike commented 3 years ago

I'm unable to load my account in iOS as well.. Well hot damn.. :P

LordMike commented 3 years ago

I've tried investigating a bit, and the moment I submit (write) data to BR, the app breaks. The API stops working for the BR app, and I'm not sure how to resolve it.. From my standpoint I'm sending back all I need, but it seems to be misinterpreted somehow.

I think I'll remove the setting of the pump schedule, as it cannot be fixed at this time.

LordMike commented 3 years ago

I'll try to reach out to BR to see if they are willing to help.. I'm not entirely sure how that'll go .. :P

kryzpee commented 3 years ago

Thanks for investigating. I also reached out to BR, but they just came up with 1st lvl bla like "Do you have the latest app version?" ;-) For now I'll try to find a way to ignore readings when the pump isn't running because I have the "BlueFit 50 issue". I read about it in the inital feature request post...

Keep up the good work!

Br, Kryz

LordMike commented 3 years ago

Yea, I've been wondering about that.. I don't think I ever figured out if readings are skipped when the pump is not running - Ie. my app should continue posting whatever it gets, or if the BR app decides to not show readings that are when the pump wasn't running - ie. the data is present, I should ignore it.

If its the latter, there is a case for my app being able to have an "enabled" / "disabled" state, that determines if data should be transmitted.. So you could in theory use that, rather than actually modifying the BR API.

kryzpee commented 3 years ago

Maybe I can help to understand with another observation:

As I have saltwater, I have the golden probe version. In settings I have set the value for disinfection to saltwater and the app shows the value for salinity. If I change the setting to chlorine, the app doesn't show the salinity value anymore, instead there's a value for conductivity. From the same measurement. I also get the value for conductivity (and even the sensor) in HA over MQTT only after switching to chlorine and syncing BR2MQTT again.

kryzpee commented 3 years ago

Thanks for investigating. I also reached out to BR, but they just came up with 1st lvl bla like "Do you have the latest app version?" ;-) For now I'll try to find a way to ignore readings when the pump isn't running because I have the "BlueFit 50 issue". I read about it in the inital feature request post...

Keep up the good work!

Br, Kryz

I've been thinking the whole day about another approach. Wouldn't it be possible to set the update interval of the MQTT2BR service to "manual" or maybe 00:00:00 and trigger a force-update over the command topic via an automation which only triggers if the pump is also running?!

LordMike commented 3 years ago

Yeap - that'd work too. You can set the interval really high, like days or weeks (or years). I don't think it works right now with 00:00:00. Reminds me I should probably add validation to ensure you don't go there, or (gasp) negative intervals.

You can write:

kryzpee commented 3 years ago

Thanks, the day variants gave me an exception. I've set the 24d one with 24:00:00

Tried 00:00:00 yesterday (before your comment) and that didn't work as you stated. But if you are over the code again (maybe for the time validation ;-)), may I suggest a manual option?! That would be awesome.

Thank you!

kryzpee commented 3 years ago

Hey again,

doesn't seem to work.

I've set: DiscoveryInterval: '24:00:00' UpdateInterval: '24:00:00' UpdateIntervalJitter: '24:00:00' UpdateIntervalWhenAllDevicesAsleep: '24:00:00'

Got the following in log: [2021-05-27 07:46:14+00:00 INF] [MBW.BlueRiiot2MQTT.Service.PoolUpdater.SingleBlueRiiotPoolUpdater] New data ready for pool 'Pool' at 05/27/2021 08:15:00 (interval 01:12:00). Waiting 00:29:50.9232021

Is this maybe because BR2MQTT gets the interval from BR?

LordMike commented 3 years ago

I'll have to look through and make changes to support this - I'll probably just implement some way of completely stopping the schedule.

NemoN commented 3 years ago

@LordMike Got the same error today (I wanted to take the Blueconnect out of winter standby) How can I do that now? The APP (Android) unfortunately no longer works.

kryzpee commented 3 years ago

I'll have to look through and make changes to support this - I'll probably just implement some way of completely stopping the schedule.

Yes, I think too. Manual trigger with the force sync topic and the schedule can be set via an automation.

kryzpee commented 3 years ago

@LordMike Got the same error today (I wanted to take the Blueconnect out of winter standby) How can I do that now? The APP (Android) unfortunately no longer works.

You have to create a new account (new mail) and connect the Blue to that one. I contacted BR support and they deleted the old (non functional) account. And be sure to update to the newest version because Mike removed the pump schedule support (as this was causing the problem).

kryzpee commented 3 years ago

I'll have to look through and make changes to support this - I'll probably just implement some way of completely stopping the schedule.

Hey Mike,

any progress on the just-manual-sync feature? I know it's summertime and many other things to do outside.... ;-)

Thanks!

LordMike commented 3 years ago

Oh no, I haven't made time for it yet.

But on the bright side, my pool is active again. So I can even test it now when it's done :)

LordMike commented 3 years ago

@kryzpee I haven't tested it yet - but it compiles. Will test later.

But a :dev image should be available soon.. :)

kryzpee commented 3 years ago

@LordMike Great news, thx! I'll wait until you finished your test because I don't wanna risk my newly created BR account ;-)

LordMike commented 3 years ago

Ah - but this change doesn't write anything to BR. It merely stops scheduling. Haven't tested it myself yet - didn't find time.

Mvh. Michael

On Fri, Jul 9, 2021 at 10:39 AM kryzpee @.***> wrote:

@LordMike https://github.com/LordMike Great news, thx! I'll wait until you finished your test because I don't wanna risk my newly created BR account ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LordMike/MBW.BlueRiiot2MQTT/issues/47#issuecomment-877019942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2YJ7LDPSG4B7QGGDRUYTTW2YU3ANCNFSM45GXXADQ .

kryzpee commented 3 years ago

Ah - but this change doesn't write anything to BR. It merely stops scheduling. Haven't tested it myself yet - didn't find time. Mvh. Michael … On Fri, Jul 9, 2021 at 10:39 AM kryzpee @.***> wrote: @LordMike https://github.com/LordMike Great news, thx! I'll wait until you finished your test because I don't wanna risk my newly created BR account ;-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2YJ7LDPSG4B7QGGDRUYTTW2YU3ANCNFSM45GXXADQ .

21-07-12 16:16:38 WARNING (MainThread) [supervisor.addons.options] Unknown option 'EnableSchedule' for BlueRiiot2MQTT Set the option 'EnableSchedule' to "false", but doesn't seem to work....

kryzpee commented 3 years ago

... and of course I used the "dev" image ;-)

LordMike commented 3 years ago

I don't think you can deploy other versions through HASS OS than the one that's published.. And even then, I don't expose the EnableSchedule option - so it's rejected.. At least it looks like you're down that route.

I managed to test the change this evening, and I discovered a minor bug that means the discovery documents are sent out too often. I'll have this fix in the next release as well. With the change, it seems to work: the schedule is ignored entirely, and updates are only performed when you do a force_sync. The force_sync cannot target any specific pool, but I think that's a minor use case.

LordMike commented 3 years ago

@kryzpee I've released 0.13.0 which contains these fixes. I have not exposed the settings via the hass-addons repo, so if you are using that let me know - then I can add it there.. I'd prefer not to add too many settings as you can't avoid showing these to users. :/

kryzpee commented 3 years ago

I don't think you can deploy other versions through HASS OS than the one that's published.. And even then, I don't expose the EnableSchedule option - so it's rejected.. At least it looks like you're down that route.

I managed to test the change this evening, and I discovered a minor bug that means the discovery documents are sent out too often. I'll have this fix in the next release as well. With the change, it seems to work: the schedule is ignored entirely, and updates are only performed when you do a force_sync. The force_sync cannot target any specific pool, but I think that's a minor use case.

You are right, I tried to fool HA with the dev image ;-) Doesn't seem to work, sorry for the bad test...

kryzpee commented 3 years ago

@kryzpee I've released 0.13.0 which contains these fixes. I have not exposed the settings via the hass-addons repo, so if you are using that let me know - then I can add it there.. I'd prefer not to add too many settings as you can't avoid showing these to users. :/

Yes, I'm using the hass-addon, would be nice if you could add it there too. I don't think thats a real problem there, because the default value is "true"... Thanks!

LordMike commented 3 years ago

The default value is as it worked before - the schedule is enabled. You wanted to disable it - so I'll add an option for it in hass-addons.

kryzpee commented 3 years ago

Works like a charm! :-) Thanks again!