Shame that issue got locked. I would have added the feedback I got from Mitsubishi. Now that my account is unlocked I will reply to them again and say that I have passed on their request about rate limiting. I already told them that the HA people are very keen to engage and ensure that the load is not unreasonable. I asked them for a link to an acceptable usage policy but they didn’t reply. I won’t push them.
Welcome back @vilppuvuorinen Would be very interested to get the flow temp changes merged upstream. What do you need for that to happen?
Upgraded to 2024.2 12 hours or so ago. Re-enabled the Melcloud integration (i had disabled it so at least my Melcloud app would work)
Integration now working again without any excessive demand lockouts. Can see the increased polling interval in the entity histories - but better that than the lockouts
Thanks to whoever it is that did the work - much appreciated.
There seems to be some variance in how different ATW devices report the flow temps. Getting it right across the whole product line would be quite a hassle.
If you really want to dig out this info I’d suggest you look into publishing the raw data (device_conf and state) from MELCloud as extra state attributes here:
The raw data can be found through these properties:
This should allow you to do some templating to turn that data into sensors on home assistant.
Thanks for the tip (not mixing REST and integration) and all the work.
My REST sensor is working again (since 8. 2. 2024 0:00). Yesterday I changed REST polling from 1 to 3 mins, not sure if this helped.
But the integration is not working yet (installed update, re-added etc).
I would love to use only one (e. g. your integration) but it does not provide all the data my heatpump sends. For example: compressor frequency, defrost state, last legionella date, …
Are there any plans to add them to the integration? I can provide names of these attributes, if it helps.
Thanks, I didn’t quite understand at the first glance, but after re-reading I realized you wanted to explain just that.
How would a template sensor for these extra states look like? Are there any examples available?
BTW: Integration works again (I had to delete - re-add it, not only disable).
Hello Trozman, Vilpu,
I did make something to get the values of my PUD-SWM80YAA Ecodan based on two REST sensors, one to update the API key and one to get the values and extract them to separate template sensors.
I am no programmer, but I use it already some months now.
Communication got worse after new-year, with almost daily hichups, but it keeps working.
Hope this could help you both for the integration of the ASHP series through melcloud.
Thanks for the examples @AWM . I already use something very similar to your example of REST sensor to get data from PUD-SHWM140YAA, I was asking if there is a possibility (and an example) to use only MELCloud integration to get additional sensors.
Hm… .that’s interesting… it seems that development goes in the opposite way of logical one… a man would expect that big companies will support integration into smarthome systems to increase sell, but quite opposite is happening: life 360 has ended in february, then Facebox…, now MelCloud doesn’t work…
where are we going?
Thanks for the information, for several days HA has not given me any data on the integrated machines and I see that they have just “limited” access to third parties.
IMHO many companies started offering cloud integrations for free to be more appealing towards customers. Sooner or later, they discovered that the one-shot cost did not pay, as these systems do have a cost for companies, and companies found these not being sustinable in the long term. Moreover, they always look for a profit, better if recurrent.
See the rumors about Alexa, with amazon willing to introduce a subscription/pay-per-use model for advanced features.
Basically, we are going towards a future with companies offering these services with a subscription model, unfortunately for us customers.
I just had a long talk with local Mitsubishi representative (they called me, because I sent them an email few days ago). A short summary:
he had no idea about the polling limitation and outages
the communication within Mitsubishi El. is bad
they are discussing opening a local API
they’re developing new version of MELCloud app, which will be released soon
general strategy is that they will not limit 3rd party integrations
he will forward my request for detailed allowed polling info and clearer and more transparent communication with customers to higher instances in Japan.
Don’t rely on this, not sure how much of this is actually true.
Thanks Trozman for the link, I just took 10mn to write an email and:
share the frustration of the community with the recent changes and the rate limiting
share the fact that since the issue, a lot of people have lost trust in relying on the cloud solution and that they are going to build / use esp32 board to gain local control
beg them to ofer a way to locally control the device using the wifi without having to use an esp32
I hope a lot more people take the time to send similar emails so that hopefully they listen and make good changes!