Same problem here after update openHAB from release build 4.2.0 to 4.2.1.
Removing and new installing the binding did not solve the problem.
HANDLER_REGISTERING_ERROR
Cannot invoke “org.openhab.binding.melcloud.internal.api.MelCloudConnection.isConnected()” because “this.connection” is null
I raised an issue for that in GitHub:
https://github.com/lucacalcaterra/org.openhab.binding.melcloud/issues/23
Exactly the same behavior as described above. Thanks for raising the Issue!
… just to be sure I copied your issue and raised it here also
Hello,
The same happened to me also after openhab-4.2.0-1.noarch.rpm → openhab-4.2.1-1.noarch.rpm update.
I tried uninstalling MELCloud binding and reinstalling it, but the same error messages after that too.
BR, Jakke
Might have created a fix. Could someone give it a test spin?
The jar is attached to this PR:
https://github.com/openhab/openhab-addons/pull/17295
Works perfect! Back online again with the provided jar (4.3.0 snapshot).
Thing “Bridge” online and discovery found all devices!
Thank you!!
I installed the JAR into openHAB 4.2.1 and MELcloud is online again.
It is working again - thank you very much!
With your fix the MELCloud Binding works fine with OpenHAB 4.2.1.
Thank you for the quick support!
Should the jar-file remain in the addons-folder forever or can I remove it later (maybe with OpenHAB 4.3.0) ?
Thanks for reporting.
It depends if this PR is backported or not. So either 4.2.2 or 4.3.0 if you stick to stable releases, or a 4.3.0 milestone. Just check the release notes or the PR to be sure.
Hello! Just got a Mitsubishi heat pump installed, and was happy to see a binding already existed. Unfortunately, it seems they have introduced a new app “MELCloud Home” that uses a new api, the account I created cannot be used to login to the old app.melcloud.com, only the new melcloudhome.com site.
I will investigate to see if the binding can be modified to support this. As I understand it, their plan is to migrate old installations to the new app as well, so needs to be changed sooner or later.
Hi,
I want to report a persistent problem with the MelCloud binding which still occurs even with the latest snapshots.
My system:
OpenHAB 4.3.5 stable release
MelCloud binding tested both with 4.3.5 built-in version and latest 5.0.0-SNAPSHOT version
Java 17
Observed behavior:
During startup, the following warnings consistently appear:
[WARN ] [.core.thing.binding.BaseThingHandler] - Handler MelCloudAccountHandler tried updating the thing status although the handler was already disposed.
In my log, for example:
11:56:22.772 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler MelCloudAccountHandler tried updating the thing status although the handler was already disposed.
11:56:23.358 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler MelCloudAccountHandler tried updating the thing status although the handler was already disposed.
Consequences:
The MelCloud Account Thing is left in a broken state.
No channels appear ("This thing has no channels. Either the thing type doesn't define channels, or they may be detected and appear later.")
Some actions like toggling power still work, but many commands (e.g., setting temperature) silently fail.
The problem happens both during initial OpenHAB startup and when manually disabling and re-enabling the Thing later.
Tested so far:
Full system reboot → problem appears.
Manual disable / enable of MelCloud Account Thing after OpenHAB has fully started → same problem.
Using latest 5.0.0-SNAPSHOT version of the binding → same problem.
Request:
I’m not speculating where exactly in the binding this issue occurs, but the consistent behavior strongly suggests that something goes wrong during asynchronous initialization of the Account Thing. I would appreciate if someone with knowledge of the binding could review and investigate this issue.
I am happy to provide further logs, tests or assist in any debugging if needed.
Thank you!
Update / additional findings:
After changing the Item definition for setTemperature to use Number:Temperature:
Number:Temperature Ln35_Set_Temperature "Set Temperature [%.1f %unit%]" { unit="°C", channel="melcloud:acdevice:myaccount:livingroom:setTemperature" }
…the binding now correctly processes set temperature commands when sent as QuantityType, and actually performs the updates via the API.
However:
The binding still fails to populate channels on startup (Thing shows “no channels”) unless I enable DEBUG logging on the binding.
Even when channels appear, the warning remains:
Handler MelCloudAccountHandler tried updating the thing status although the handler was already disposed.
So the race condition during initialization still exists, but at least the temperature command conversion works correctly now with proper QuantityType items.
With the provision that I do not have this binding, I did see this message while adding to the Midea AC development. The cause in my case was that java timer/scheduler(s) in the binding do not get turned off and keep running and trying to do an action on something that is not there. IMO some of your actions should have worked, so there could be something specific in the binding that I don’t understand. However, if your issue is related, disabling/ enabling the Thing is probably the worst action.
I would try removing the binding completely (leave Thing), stop OH, clear cache (to ensure nothing is left that will restart the schedulers), then restart OH. Since this seems to happen right away, wait until OH is settled, then reinstall the binding. (One more idea, before removing the binding, if there are timing items for polls and cloud connections in the Thing configurations extend them). The main thought with this is that OH java needs to be shut down and cleared to get rid of the scheduler(s). However, delaying the binding installation until well after startup and increasing the intervals might help too.
About the Wide vane thing, did you confirm that it can be done also with the melcloud app (app.melcloud.com)?
If it is the case, can you open the browser dev tools in the network tab and try to change the parameter? this should show you something like SetAta on the left column and the data exchanged with the server. Of course, this is a bit tricky cause i have no AtA devices…
Thanks for guiding me to the parameters - that’s interesting 
The “direction” as shown on the remote does not exist on app.melcoud.com. That would explain why we cannot control it via openHAB.
I searched for “direction” but it is not available.
Yes, it help 
do you think we can go on on a 1 to 1 conversation? I think the reverse eng can be tedious for all the other users…
sure, np.
May I ask if there is any news on the melcloud home integration?
Testing version is available at Marketplace - Mitsubishi MELCloud Home
Discovery is fine. But I had to copy the jar to the addons folder.
