Looks like the unavailable status is fixed, but the app does not update real life status on ACs. Currently one of mine is running, but according to the app it doesn’t and also does not respond to ON/OFF etc.
Same for me
Fredrik
Skickat från min iPhone X
@J33bee @Fredrik_Johansson1 - I can explain what’s happening, and there’s a fix ready.
The status-not-updating / no response to ON/OFF you’re both seeing right after the v4.2.0 update is a bug in the AMQP connection to Toshiba’s cloud (used for real-time status updates and commands), not something on your end.
Root cause: the Azure IoT client the app uses emits an error event when the SAS token gets rejected by Toshiba’s servers. Without a listener on that event, Node.js treats it as an uncaught exception - which used to crash the whole app (that’s the “Unavailable” state some of you saw, including the 401/403 loop @Lloyd_Nedrum reported). On top of that, even the reconnect logic that was supposed to recover from this never actually worked: it only updated a local variable with the new token but never pushed it onto the live connection, so AMQP silently stayed broken until a full app restart.
I’ve fixed both issues (added the missing error handler + fixed the reconnect to actually call Azure’s updateSharedAccessSignature()), plus added similar auto-recovery for the main API login token expiring (401/403 on energy consumption calls). Tested live against my own Homey Pro: reproduced the crash, confirmed it now recovers instead of crashing or getting stuck.
@Monique_Jilesen whenever you get a chance!
Impressive work! I indeed saw the app crashing multiple times after updating.
most of the credits are for Claude
Thanks Max, you are the best!
It all works again, I/m verry happy with that!
Br Henk.
Works fine. Thank you very much.
Still no luck overhere. Looks like the latest fix, is not pushed yet?
@Max_Westerveld hmm I logged out and logged in again on the Toshiba app (from Toshiba). Then I restarted the Toshiba app on the Homey and now it works!
All OK again since update to app version 4.2.0. Thanks!!!
I just did the same thing and now it’s working.
@Monique_Jilesen - since the SAS-token fix (#97) I’ve kept digging into this codebase: fixed the app crash on AMQP auth failures, the reconnect logic that turned out to be a no-op, added 401/403 recovery on the main API token, and just now the sparse/missing temperature updates too. All in PR #98, tested live on my own Homey Pro each time.
At this point I’m pretty deep in the weeds here and honestly enjoying it. You mentioned at some point maybe handing the repo over - if that’s still something you’d want, I’m happy to take it on and keep maintaining it.
Great @Max_Westerveld really happy if someone can continue this great app, thanks!
I’d also like to submit a feature request, if that’s possible. Maybe I’m the only one experiencing this, but I thought I’d mention it.
This only happens in the Homey app for iOS (I don’t use Android, so not able to test). In the web-based Homey interface (browser), everything is displayed correctly for me.
When I want to change the fan speed, the app always opens the Merit B option first. I never use this option. It would be much more convenient if it opened directly to the Fan Mode menu instead, so I can immediately select the desired fan speed.
@J33bee This is the same for android so I can reproduce your issue. That would make solving it less complicated. Must be setting some value default I’d guess.
But first things first. Let’s wait for @Monique_Jilesen s reaction on my previous post
.
I’m having exactly this issue now after updating to 4.2.1. Any ideas?
I also have issues with my flows. When turning off my ACs via the already existing flows, it turns OFF and immediately ON again, so it stays on*… Other people also have this?
*Homey & Toshiba think it’s off, because both apps show it’s OFF, but still ON.
Could you please check if the “Zet uit” turn off function is working properly? It looks like it “fires” two times shortly after each other because the lid closes a tiny bit and then opens again, so the AC stays on.
I’m experiencing the same issue. Using the Toshiba app the AC’s are working fine, using Homey some AC’s do not turn off anymore. Some do, although the WiFi adapter software version is identical
Running Toshiba app 4.2.1
@dsnet — that matches what I found: I traced a race condition in the status poll added in 4.2.0 (initStatusPolling). Toshiba’s cloud-side snapshot can briefly lag behind right after a command, and if the poll lands in that window it overwrites the state you just set with stale data from the cloud. Fix + PR here: Fix status poll overwriting recently commanded AC state by WitteKnol · Pull Request #99 · mjilesen/com.toshiba · GitHub
@J33bee @Maurice_Janssen — your “fires twice, lid closes then reopens” observation might be a related but distinct issue (possibly the AMQP off-command itself getting redelivered rather than a status overwrite) — I haven’t been able to fully confirm that mechanism yet. Worth trying PR #99 first since it may already resolve it, but if it’s still happening afterward, let’s dig into it further — app logs from right around the moment it happens would help a lot at that point.
Appreciated @Max_Westerveld let me know if we can test/generate logfiles!
Hi Max, pretty happy to hand things over to you. I need to transfer the app from my Homey developer account to yours. Therefore I need your developer account id (can be found on the Homey developer site, My Account).
It is up to you if you want to clone my repro and publish from that or I can move ownership to you (need your github username).
You can email them to monique.jilesen.homey@gmail.com
Hi @Max_Westerveld,
I still have the issue on 4.2.3. I already rebooted both the Toshiba Homey app and the Homey itself.
