That would be great. I haven’t had time to do anything more for a long time, and some changes are looooong overdue!
I chose not to create a specific OpenHAB binding, and rather use MQTT, firstly because I didn’t have time to learn how to build OpenHAB bindings, and later since an MQTT-based bindings is more flexible in that it can be used for other home automation systems as well.
When it comes to development needs, I have seen two clear needs:
Automatic renewal of OAuth2 tokens does not seem to work, so you have to reauthenticate every now and then. I suspect this might be a backend (i.e. Miele) issue, but wish I could verify it. I could probably try these days, as I believe my token has expired, so I should renew it anyways.
The script currently does not support two-way communications, so you cannot send commands to the machines. This proved to be more difficult than anticipated. I have spent some time on it. Current plan is to switch from using native MQTT client to phpMQTT (https://github.com/bluerhinos/phpMQTT).
Hi Ole,
can we also provide a JSON file output instead of MQTT as an option. This might be useful as maybe not everybody wants to uses MQTT, and is easy to add.
I am still struggling to get everything to run, I get an error that my credentials are wrong…
Regards,
Kurtus
I have now updated the script, using Bluerhinos’ library, as planned. It is now possible to issue commands to devices through the script. The script is in no way optimized, and I assume any professional programmer would want me banned from ever posting any code again, but it works
A major change to the script is that it now runs continuously (a hard requirement in order for it to be able to pick up commands through MQTT). I am seriously considering adding a switch to make it run only once (with no commands supported), and a switch to just have it output JSON and then exit. In that case, I would just dump the JSON as delievered by Miele, so you would have to read out the needed values for yourselves.
Hi Ole, actually I don’t like the basic idea of using the Miele platform for all commands and/or requests. The Miele platform is just too unreliable and sometimes not quick enough.
I want to analyse the data itself which is sent by Miele to the devices in order to be able to have control and read statuses directly. (and efficiently)
Another issue is that the control possibilities are so limited at this moment. (at least concerning my equipment)
Concerning the OAuth2, I normally send API or usercredentials in the http_header using curl_setopt in every POST. But I did not try anything on this Miele project yet.
Hello, Rolf!
I completely agree that using Miele’s backend is less than perfect. I suspect the appliances to connect directly to Miele through HTTPS, although I haven’t checked this. This would mean you need to perform a successful man-in-the-middle attack in order to actually be able to read the data. If you succeeded in decrypting packages, and finding out what is happening, you would probably need to proxy (or completely hijack) connections from appliances to Miele’s backend servers, which is an unlikely scenario for most people. If you ended up hijacking, by overriding Miele’s DNS with your own, internal DNS, you would probably end up never getting any firmware upgrades.
-But hey, if you are able to make something, I would love to test it, and to discuss possibilities. For me, I just needed something that could give me “time remaining” on my kitchen-mounted screen
hehe, I guess I’m not easily satisfied. Maybe I end up with an ESP32 to replace the ‘Kommunikationsmodul’ just to have extra input/output possibilities.
All communication takes place via your own router/modem, and I suspect the security level not to be that sofisticated…
Inspired by you, I now did a quick check, and I can see that my dishwasher sends a multicast DNS query regularly, asking for “_mieleathome._tcp.local”. I assume this is a name that the communication gateway (XGW 3000) would respond to. So, it would of course be interesting to see what happened if you added a device in the network claiming that name, with a listener on port 80 and 443.
I just noticed in my currently running tcpdump, that a public IP is contacted on port 80. The dishwasher is off at the moment, so this may just be a “ping” to tell Miele that it is here, and turned on, but I have turned on some options to show me the actual HTML now, so hopefully I will be able to see what it actually does.
The code has now been updated, to add support for command switches, and everything else that we have been talking about. There may naturally be some bugs, but I feel this version can probably live for a while.
Mark: As mentioned yesterday, I changed MQTT to use phpMQTT.php, provided by Bluerhinos, available here: https://github.com/bluerhinos/phpMQTT. This file needs to be in the same directory as miele-MQTT.php.
The communication over port 80 doesn’t look like plain HTML (although I haven’t properly confirmed this). It runs every hour, most likely to tell Miele that the device actually is present.
Hehe, sorry, I am not at home, and remote start is not possible. I haven’t had the need, so I haven’t checked if it is possible to enable remote start, or if it is actually not possible on this model.
In the app you can tick the box jeans and it starts your machine with the right program. (also the more complicated combinations, therein lies the gain)
Hehe, I am quite familiar with networks, tcpdump and Wireshark, and have used it extensively in the past
It looks like Miele use a proprietary protocol over port 80, but I would need to turn on my dishwasher and log the traffic into a pcap file for examination through Wireshark to find out. For now, I used tcpdump directly on my router to display packets, but naturally, now I only see the “ping” once every hour from the dishwasher.
My fears of going this direction are:
We might not be able to decrypt the traffic going. It may very well be encrypted or just obfuscated in some proprietary way. In order to decrypt, we need to figure out how this is done.
There might be commands / traffic patterns that we should know, but that do not happen often enough for us to detect it.
Firmware upgrades may be a double-edged sword. Miele may very well create new firmwares that support new communication methods as time moves along. Since their internal protocol is not documented, they are free to change it whenever they feel for it, as long as they do not break functionality. However, writing software that communicates directly with appliances, we would have to stay up-to-date. -So we would need to build support for all and any communication changes that may show up, and the only way to do that, besides keep buying new expensive appliances, would be to always stay on the latest firmware. -Which means we would need to either directly support firmware upgrades, or pass that traffic through to Miele’s back end.
So, as I see it, there are definitely some challenges here. However, I remember I have read some posts in the Deconz (I believe it was) forum a couple of years ago, where they were actually decoding Miele’s communication. So I’ll head over there, and see if I can gather some info.
In regards to C. you can think of an interface/dashboard in OpenHAB to select a dinner which initiates sending the right settings to your Steamoven, the normal Oven (for the second step) and to whatever machines (brands) are needed in that cooking proces.
Off course all things are upgraded, updatet and changed. Even subtle changes in menus will be made (by Miele) when they find out that an ingredient is better cooked in 6 minutes rather than 8. That’s is where the Miele backend comes in especially! Use it for making the clientside database automatically build/filled and updatet. (allways compare the API backend reply with the local database)
So, this little diswasher-timer-display function you were up to, offers something beyond…
Fabulous! -And as it seems (from my brief read) that the people developing this are actual representatives from Miele, it means that any changes in the API will be taken into account! This is perfect news!!
Very nice! (although it doesn’t state when they are planning to deliver)
And I like seeing they have a lot more functionality in the pipeline too. Cool!
just to have extra input/output possibilities.