Thanks Johnny. I will ask Robert if Homekitty could also trigger onoff when changing thermostat mode. If not, I will implement your workaround.
Regards
Dennis
Thanks Johnny. I will ask Robert if Homekitty could also trigger onoff when changing thermostat mode. If not, I will implement your workaround.
Regards
Dennis
Thanks. Just set up the flows. Unfortunately it doesnāt workto turn the AC on via HomeKit. The thermostat mode is changed as I can see (blue dot behind temp on the tile of the device). But it doesnāt turn on. Activating the flow in the homey app turns it on fine though. But turning it off works via HomeKit and homey app. Strange. Maybe thatās the change you implemented to change the mode to off when the AC is turned off?
After looking into it more, the Homey flow approach unfortunately doesnāt work reliably when the trigger comes from an external bridge like HomeKitty ā Homey only fires those flow triggers
for changes initiated within Homey itself, which is why it worked when you activated it manually but not from HomeKit.
So I went ahead and made the change in the app after all. Version 2.1.18 is out ā changing the thermostat mode to cool/heat/auto will now automatically turn the device on as well. No flows
needed, it just works.
Sorry for the detour!
Sounds great. Thank you so much! Will test it tomorrow ![]()
Hi, Iāve got a new homey pro, a Panasonic airconditioning connected to the comfort cloud and app working. Checked username password several times. Still when trying to add my airco I cannot get passed the authorization. Wrong username. Removed app, restarted homey, reinstalled, same issue. What am I doing wrong here? Thanks, Bert
Just below the credential fields there is a sign in button, have you tried that?
Yeah, at least 20 times. This morning I added my phone number to my Comfort Cloud account (you try anything) and, ⦠IT WORKED! Got through authentication. Thanks for your work and response.
I had the app installed with 3 units. But since some weeks they stopped working (message: could not reach panasonic cloud). Today I uninstalled the app and reinstalled the comfort cloud app in homey pro. Now, when adding new units I need the authenticate, but when entering email and password, clicking the sign in button it says āNo redirect from authorizeā.
Strange..could you try to send me a diagnostic report from the homey app?
This is de code for the diagnostic report: 29c46238-c45d-4a1b-ba9f-4b55c494624b
Great. Have you tested your account on the official panasonic app?
Yes. I can login when on cellular. But when Iām on local WiFi it looks like Iām blocked out by Panasonic, since I will only get that messsge then. And the homey is in my local network so it seems itās blocked by ip.
I checked the login attempts in my Panasonic account, and it show login attempts, for every minute for a long period. It stopped at 18-6 (thatās also when the integration stopped working).
So it looks like the homey-integration tried to login every minute for a longer period and therefore Panasonic blocked my local ip. Are you familiar with this issue? I already reached out to Panasonic support for whitelisting my ip, but there seems to be something wrong with the integration.
Thank you for this app. I am currently using a Home Assistant integration to control my heat pumps and I am looking forward to move my code to your app. While doing the migration, I have noticed the following issues.
Using the developer tools web site, when I inspect a device created by your app, the domain of the capability āpanasonic_swing_udā goes from 0 to 4 instead of 0 to 5.
I have 2 outside compressors, one working with only one internal unit and the other with 2. The 1 compressor - 1 internal units combo works fine with your app. However with the outside compressor with 2 internal units:
Next is a feature request, It would great is you could support the Eco mode of the newer heat pumps.
Thanks again.
What happened: When sign-in fails repeatedly for an account, older versions of the app would retry the full login every single minute (matching the poll interval). Panasonicās servers see that as abusive traffic and respond by temporarily blocking the source IP. Thatās why itās network-specific for you: your phone on cellular uses a different IP and still works, while your home WiFi (same network as your Homey) is the IP that got blocked.
So there are two separate things going on:
The IP block is on Panasonicās side ā nothing in Homey can clear it. Reaching out to Panasonic support to unblock/whitelist your IP (which youāve already done
) is the right move. In many cases it also clears on its own after a while.
The app shouldnāt have hammered the login in the first place ā thatās a bug, and itās now fixed.
The fix (v2.1.20):
Itās on its way through the app store now.
What Iād suggest on your end:
Wait until Panasonic has lifted the block on your home IP (test by trying the official Panasonic Comfort Cloud app while on home WiFi ā once that works, the block is gone).
Update the Homey app to 2.1.20 once itās live.
Re-add/re-pair the device and re-enter your credentials, just to be sure the stored login is current. A persistent sign-in failure is usually caused by a changed password (or a 2FA/account prompt) on the Panasonic account ā if your password was changed at any point, the old one stored in Homey would have been what kept failing. Worth double-checking that.
Let me know how it goes once your IP is unblocked and youāre on 2.1.20
This is most likely expected rather than a bug. Up/Down has 5 physical vane positions (Top, Close-to-Top, Middle, Close-to-Bottom, Bottom), so the capability exposes values 0ā4. Left/Right has more positions (up to āWideā), which is why it goes higher. One difference from the Home Assistant integration: this app exposes the auto/swing state as a separate toggle (Auto Swing Up/Down) rather than as a value inside the position list, so the position enum has one fewer entry than you may be used to.
That said ā if your unit actually reports an airSwingUD value of 5 at some position, then Iām missing it and should add it. Could you check in the developer tools what raw airSwingUD value the unit reports for the position that looks missing? If itās a real 5, itās a quick fix.
Youāve diagnosed this correctly. On a multi-split, Panasonic meters the outdoor compressor and reports that same consumption against each indoor unitās device ID. The app reads energy per device, so two indoor units each report the full outdoor figure ā which is why it looks doubled.
Thereās no per-indoor breakdown available from the Panasonic API, so I canāt split it cleanly. The possible workaround is to use the group/topology info to detect indoor units that share an outdoor unit and only attribute the energy once. Iād like to look into that ā if you can paste the group structure from the developer tools (the device list grouping), thatāll help me design it.
This one was a real bug on my side, and itās now fixed in v2.1.21. The app was marking a device āunavailableā after a single failed poll. On accounts with several indoor units there are more requests per minute, so a brief blip or a transient rate-limit from Panasonic would instantly flip a unit offline, then the next poll would bring it back ā exactly the flapping you saw, and why everything looked fine in Home Assistant and the Panasonic app. The app now tolerates short outages (a few consecutive misses, or a few minutes) before reporting unavailable. Please update to 2.1.21 and let me know if the flapping stops.
Happy to look at adding this. I just need to know which parameter your unit uses for it, since it varies by model. Could you paste the raw āparametersā JSON for one of the newer units from the developer tools ā ideally one capture with Eco on and one with it off? That lets me identify the exact field and add a proper toggle/flow card for it.
Since this weekās update, the device has been offline. Even after removing it and adding it again, the device remains unavailable.
Please send diagnostic report
fre. 26. juni 2026, 09:19 skrev Jesse Bakker <notifications@athom.discoursemail.com>:
I created and submitted a diagnostic report: 9d8b7064-69fd-4308-84f9-1f3bd8680c5b