MieleRESTServer -- Miele@home Without Cloud Possible

Development
141

Many thanks. I think I can pinpoint what module your device has based on that text (which also explains why it doesn’t work). To confirm I am indeed looking at the same module, could you please try to access the following:

/TimeSync
/license
/liCeNseblablabla
/Devices
/Devices/001D63FFFEB2EDCA/TimeSync
/Devices/001D63FFFEB2EDCA/Update
/Devices/001D63FFFEB2EDCA/State
/Devices/001D63FFFEB2EDCA/Ident
/Devices/001D63FFFEB2EDCA/DOP2
/Devices/001D63FFFEB2EDCA/DOP2?idx1=1&idx2=0

The tentatively good news is that this seems to be just a software issue. Your module appears to be in hardware identical to the EK057S, which is compatible.

142

Bot the license endpoints:
/license
/liCeNseblablabla

return the same license.txt file. If I’m in APP pairing mode, the are accessible over HTTPS only, once the device is rebooted they are available via HTTP

/Devices is indeed accessible only in pairing mode, and returns what seems to be the group ID:

--2025-12-30 09:26:41--  https://192.168.188.145/Devices
Connecting to 192.168.188.145:443... connected.
WARNING: The certificate of ‘192.168.188.145’ is not trusted.
WARNING: The certificate of ‘192.168.188.145’ doesn't have a known issuer.
The certificate's owner does not match hostname ‘192.168.188.145’
HTTP request sent, awaiting response... 200 OK
Length: 77 [application/vnd.miele.v1+json]
Saving to: ‘STDOUT’
{
	"000207355092":{"href":"000207355092/",		"Group":"",
		"Pairing":false
}
}

Neither TimeSync, nor the /DEVICES//* ones are accessible they all return 404.

143

VERY interesting. The fact that the “licenseblablabla” endpoint returns the same document confirms that I am looking at the right code. This device seems to match only on the first letters of the endpoint. So we’re getting closer.

Please try https://192.168.188.145/Devices/000207355092/ next. And if returns any additional endpoints with “href”, try these as well.

144

unfortunately

/Devices/000207355092/

also returns with 404

145

@schneidair

Thanks for the additional info.
It seems there are indeed devices that have broken provisioning functionality. @bencope may have another one. However, it looks like they aren’t completely inaccessible, but may simply use a hardcoded key.

To see if this is genuinely the code path your device is stuck in, please try if it changes anything if you change your Curl script as per the below? (Obviously the authentication header is wrong, but it should trigger a different error code, proving that the device is waiting for an authorization header rather than just being non-functional.)

Also, looking at your packet dump, you are saying the device does not broadcast its group, but the screenshot you are showing would not show it regardless. The group field is in some deeper level in the packet payload, which isn’t shown. Is it genuinely not in there?

Happy new year.

#!/bin/bash
MIELEIP="$1"
PROTOCOL=https
# Test the following endpoints by outputting the HTTP response to stdout
TARGETS=(
    /WLAN 
    /Ident
    /State
    /profUser/users
    /profUser/roles
    /Security/Cloud
    /Settings
    /profFileTransfer
    /profLock
    /PROF
    /DOP2curl
)

# check if device is reachable, exit if not
ping -c 1 -W 1 "$MIELEIP" > /dev/null 2>&1
if [ $? -ne 0 ]; then
    echo "Device $MIELEIP is not reachable."
    exit 1
fi  

# testing each endpoint, printing the response
for TARGET in "${TARGETS[@]}"; do
    echo "Testing endpoint: $TARGET"
    curl -H "Authorization: MieleH256 1111111111111111:DD361380F1AB6BC95C3A42144DA458CB58A204A4A509E14B59B7690D1846AAE3" -k "$PROTOCOL://$MIELEIP$TARGET"
    # do the same with wget

    echo -e "\n"
done
'''
146

dont know if it helps, but on mine I get connection refused using https and 404 for everything using http

147

Thanks for checking. Then you’re not on the code path I was looking at. Next attempt below.

Appreciate you both bearing with me, these things seem to have a somewhat complex state machine of when exactly they accept what command…

#!/bin/bash
MIELEIP="$1"
PROTOCOL=https
# Test the following endpoints by outputting the HTTP response to stdout
TARGETS=(
    /WLAN 
    /Ident
    /State
    /profUser/users
    /profUser/roles
    /Security/Cloud
    /Settings
    /profFileTransfer
    /profLock
    /PROF
    /DOP2curl
    /Security
    /Security/Commissioning
)

# check if device is reachable, exit if not
ping -c 1 -W 1 "$MIELEIP" > /dev/null 2>&1
if [ $? -ne 0 ]; then
    echo "Device $MIELEIP is not reachable."
    exit 1
fi  

# testing each endpoint, printing the response
for TARGET in "${TARGETS[@]}"; do
    echo "Testing endpoint: $TARGET"
    curl -H "Authorization: Miele Pairing:Pairing" -H "Miele Pairing:Pairing" -k "$PROTOCOL://$MIELEIP$TARGET"
    # do the same with wget

    echo -e "\n"
done
'''
148

I just discovered the video, so maybe it has zero new information, but the talks from the event series are usually done very thoroughly. It focusses on the data busses directly though, not on the network interface.

149

Happy new year to you too!

I’ve tried both variants of your script but did add -v for more output. Trying both pre and post assigning the IP resulted in the same output:

for all but one of the endpoints receive 404:

Testing endpoint: /WLAN
*   Trying 192.168.188.145:443...
* Connected to 192.168.188.145 (192.168.188.145) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=DE; O=Miele & Cie. KG; CN=Secure Communication EK05x Supplier-A; OU=A.1.1-1124689062461089800989381655021990065942013167964
*  start date: May 28 13:43:54 2025 GMT
*  expire date: Feb 15 00:00:00 2099 GMT
*  issuer: C=DE; O=Miele & Cie. KG; CN=Secure Communication EK05x Supplier-A CA; OU=A.1.1
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* using HTTP/1.x
> GET /WLAN HTTP/1.1
> Host: 192.168.188.145
> User-Agent: curl/7.88.1
> Accept: */*
> Authorization: MieleH256 1111111111111111:DD361380F1AB6BC95C3A42144DA458CB58A204A4A509E14B59B7690D1846AAE3
>
< HTTP/1.1 404 Not Found
< Date: Sat, 03 Jan 2026 14:51:47 GMT
< Content-Length:0
< Content-Type: application/vnd.miele.v1+json; charset=utf-8
<
* Connection #0 to host 192.168.188.145 left intact

and

Testing endpoint: /WLAN
*   Trying 192.168.188.145:443...
* Connected to 192.168.188.145 (192.168.188.145) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=DE; O=Miele & Cie. KG; CN=Secure Communication EK05x Supplier-A; OU=A.1.1-1124689062461089800989381655021990065942013167964
*  start date: May 28 13:43:54 2025 GMT
*  expire date: Feb 15 00:00:00 2099 GMT
*  issuer: C=DE; O=Miele & Cie. KG; CN=Secure Communication EK05x Supplier-A CA; OU=A.1.1
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* using HTTP/1.x
> GET /WLAN HTTP/1.1
> Host: 192.168.188.145
> User-Agent: curl/7.88.1
> Accept: */*
> Authorization: Miele Pairing:Pairing
> Miele Pairing:Pairing
>
< HTTP/1.1 404 Not Found
< Date: Sat, 03 Jan 2026 14:52:43 GMT
< Content-Length:0
< Content-Type: application/vnd.miele.v1+json; charset=utf-8
<
* Connection #0 to host 192.168.188.145 left intact

But for the /Security/Commissioning there is a different result with a more expected 405:

Testing endpoint: /Security/Commissioning
*   Trying 192.168.188.145:443...
* Connected to 192.168.188.145 (192.168.188.145) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=DE; O=Miele & Cie. KG; CN=Secure Communication EK05x Supplier-A; OU=A.1.1-1124689062461089800989381655021990065942013167964
*  start date: May 28 13:43:54 2025 GMT
*  expire date: Feb 15 00:00:00 2099 GMT
*  issuer: C=DE; O=Miele & Cie. KG; CN=Secure Communication EK05x Supplier-A CA; OU=A.1.1
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* using HTTP/1.x
> GET /Security/Commissioning HTTP/1.1
> Host: 192.168.188.145
> User-Agent: curl/7.88.1
> Accept: */*
> Authorization: Miele Pairing:Pairing
> Miele Pairing:Pairing
>
< HTTP/1.1 405 Method not allowed
< Date: Sat, 03 Jan 2026 14:52:54 GMT
< Content-Length:0
< Content-Type: application/vnd.miele.v1+json; charset=utf-8
< Allow: PUT
<
* Connection #0 to host 192.168.188.145 left intact

My interpretation would be, that the /Security/Commissioning is available but requires some authentication default authentication parameters :thinking:

150

Progress!! I actually think you’re past the authentication stage (which gave you 404 previously), but now it complains that /Security/Commissioning is a PUT endpoint, not a GET, hence “Method not allowed”. This matches the behavior on other devices I have seen (you cannot read the key, only set it). So let’s send a PUT with the new authentication header we found – script below. This should now get error 500 since there is no valid payload.

If this also works, you can simply add the --header=“Authorization: MielePairing:Pairing” flag in the provision-key.sh and try to actually upload the key. :slight_smile:

I also discovered another endpoint that the device apparently uses when provisioning SuperVision devices, /Security/HAN. So I added this into your “endpoint scanner” script as well. EDIT – even more endpoints. added them all

#!/bin/bash
MIELEIP="$1"
PROTOCOL=https
# Test the following endpoints by outputting the HTTP response to stdout
TARGETS=(
    /WLAN 
    /Ident
    /State
    /profUser/users
    /profUser/roles
    /Security/Cloud
    /Settings
    /profFileTransfer
    /profLock
    /PROF
    /DOP2curl
    /Security
    /Diagnose
    /Diagnose/XKMReset
    /Devices/000207355092/Diagnose
    /Devices/000207355092/Diagnose/XKMReset
    /Security/Commissioning
    /Security/HAN
    /Security/Cloud
    /Security/Cloud/TAN
    /Security/Cloud/Stage
    /Security/Cloud/CD
)

# check if device is reachable, exit if not
ping -c 1 -W 1 "$MIELEIP" > /dev/null 2>&1
if [ $? -ne 0 ]; then
    echo "Device $MIELEIP is not reachable."
    exit 1
fi  

# testing each endpoint, printing the response
for TARGET in "${TARGETS[@]}"; do
    echo "Testing endpoint: $TARGET"
    curl -H "Authorization: Miele Pairing:Pairing" -H "Miele Pairing:Pairing" -k "$PROTOCOL://$MIELEIP$TARGET"

curl -X PUT -H "Authorization: Miele Pairing:Pairing" -H "Miele Pairing:Pairing" -k "$PROTOCOL://$MIELEIP$TARGET"
    # do the same with wget

    echo -e "\n"
done
'''
151

I was so excited for this! But unfortunately it doesn’t work for me. I get the 405 but still 403 with the magic headers :pensive:

152

@bencope
Your device is also special but in a different way. scheidair’s device has no group set, yours has a mystery group set. Let’s get some more information on yours. When you try to set the key (where you get the 403), can you please dump the headers (curl -vvv or wget --save-headers )? Mainly I want to see whether your device sends signed responses. scheidair’s doesn’t.

Also, can you run the endpoint scanner script please?

Thanks

153

SUCESS! adding --header=“Authorization: MielePairing:Pairing” in the provision-key.sh did the trick.

I finally managed to read from my washer. The App pairing failed after the executing provision-key.sh. The washer showed a generic error message that the connection failed, with the option to repeat the process or cancel.
Cancelling and activating Miele@Home worked however and now I can read the summary:

    "washer": {
        "Status": 2,
        "InternalState": 0,
        "ProgramType": 1,
        "ProgramID": 0,
        "ProgramPhase": 256,
        "RemainingTime": [
            0,
            0
        ],
        "StartTime": [
            0,
            0
        ],
        "TargetTemperature": [
            -32768,
            -32768,
            -32768
        ],
        "Temperature": [
            -32768,
            -32768,
            -32768
        ],
        "SignalInfo": false,
        "SignalFailure": false,
        "SignalDoor": true,
        "RemoteEnable": [
            15,
            0,
            0
        ],
        "ProcessAction": 0,
        "DeviceAction": 0,
        "Light": 0,
        "StandbyState": 1,
        "ElapsedTime": [
            0,
            0
        ],
        "SpinningSpeed": 0,
        "SyncState": 2,
        "DeviceType": 1,
        "SubType": 0,
        "DeviceName": "",
        "AppSupport": 313,
        "FctSupport": 3,
        "XKMSupport": 7,
        "ProtocolVersion": 4,
        "DeviceIdentLabel": {
            "Version": "E",
            "FabNumber": "000207355092",
            "FabIndex": "54",
            "TechType": "WWG760",
            "MatNumber": "11357850",
            "SWIDs": [
                6456,
                20456,
                25213,
                25191,
                25446,
                25205,
                25447,
                25319
            ]
        },
        "XKMIdentLabel": {
            "Version": "E",
            "FabNumber": "000000598612",
            "FabIndex": "00",
            "TechType": "EK057S",
            "MatNumber": "12597311",
            "SWIDs": [
                6430
            ],
            "ReleaseVersion": "09.12"
        },
        "DecodedProgramPhase": "WashingMachineIdle",
        "DecodedProgramID": "NotSelected",
        "DecodedStatus": "On",
        "DecodedDeviceType": "WashingMachine",
        "RemainingMinutes": 0,
        "ElapsedMinutes": 0,
        "Progress": "0.0"
    }
}

Just for completeness i was able to squeeze out the follwoing errors:

Endpoint GET return code PUT return code
/WLAN 404 Not Found 400 Bad Request
/Security 404 Not Found 400 Bad Request
/Diagnose 405 Method not allowed 400 Bad Request
/Security/Commissioning 405 Method not allowed 400 Bad Request
/Security/HAN 404 Not Found 400 Bad Request
/Security/Cloud 404 Not Found 400 Bad Request
/Security/Cloud/TAN 405 Method not allowed 400 Bad Request
/Security/Cloud/Stage 405 Method not allowed 400 Bad Request
/Security/Cloud/CD 405 Method not allowed 400 Bad Request

All other endpoints returned 404 for both GET and PUT.

Thanks alot for your help!

154

Glad to hear! :slight_smile: Please try out remote start and the DOP2 endpoint (/washer/walkdop2tree) as well.

I don’t think there’s any harm in including the new header on devices that don’t need it, so I’ll just update the provision-key script to always include it. You didn’t have to make any other changes apart from the header to that script for it to work, right?

155

I did also uncomment the HTTP line, as it is not supported by my washer. But this should not matter.

I’ve uploaded my dop2tree output, in case you’re interested Download walkdop2tree.json | LimeWire

Remote start did not work, as i cannot preconfigure the program on the device itself. i would need to do that prior to starting.
thus the /start endpoint returns

{
    "DeviceReadyToStart": false,
    "DeviceRemoteStartCapable": true
}

But this is not so important, as i’m not plaing to use remote start.

156

Testing endpoint: /WLAN 404 400
Testing endpoint: /Ident 404 404
Testing endpoint: /State 404 404
Testing endpoint: /profUser/users 404 404
Testing endpoint: /profUser/roles 404 404
Testing endpoint: /Security/Cloud 404 400
Testing endpoint: /Settings 404 404
Testing endpoint: /profFileTransfer 404 404
Testing endpoint: /profLock 404 404
Testing endpoint: /PROF 404 404
Testing endpoint: /DOP2curl 404 404
Testing endpoint: /Security 404 400
Testing endpoint: /Diagnose 405 400
Testing endpoint: /Diagnose/XKMReset 404 404
Testing endpoint: /Devices/000207355092/Diagnose 404 404
Testing endpoint: /Devices/000207355092/Diagnose/XKMReset 404 404
Testing endpoint: /Security/Commissioning 405 400
Testing endpoint: /Security/HAN 404 400
Testing endpoint: /Security/Cloud 404 400
Testing endpoint: /Security/Cloud/TAN 404 400
Testing endpoint: /Security/Cloud/Stage 404 400
Testing endpoint: /Security/Cloud/CD 404 404

17:39:35.880086 [0-0] => Send header, 181 bytes (0xb5)
0000: PUT /Security/Commissioning HTTP/1.1
0026: Host: 172.29.18.126
003b: User-Agent: curl/8.14.1
0054: Accept: */*
0061: Authorization: Miele Pairing:Pairing
0087: Miele Pairing:Pairing
009e: Content-Length: 176
00b3: 
17:39:35.880785 [0-0] => Send data, 176 bytes (0xb0)
0000: {"GroupID": "729122BF1559A305", "GroupKey": "A4E0213432550EF87A3
0040: 05D99E78343A121481000B22A66FD05FEA3C0A310AAB51EEEFBE02BF1490B084
0080: 62D151CFB4D3976D3D016548358AE4B13D34DDF5C7C9F"}.
17:39:35.881365 [0-0] == Info: upload completely sent off: 176 bytes
17:39:35.900440 [0-0] <= Recv header, 24 bytes (0x18)
0000: HTTP/1.1 403 Forbidden
17:39:35.900834 [0-0] == Info: [WRITE] [OUT] wrote 24 header bytes -> 24
17:39:35.901198 [0-0] == Info: [WRITE] [PAUSE] writing 24/24 bytes of type c -> 0
17:39:35.901556 [0-0] == Info: [WRITE] download_write header(type=c, blen=24) -> 0
17:39:35.901995 [0-0] == Info: [WRITE] client_write(type=c, len=24) -> 0
17:39:35.902303 [0-0] <= Recv header, 37 bytes (0x25)
0000: Date: Fri, 02 Jan 1970 21:03:24 GMT
17:39:35.902726 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=37) -> 0
17:39:35.903057 [0-0] == Info: [WRITE] [OUT] wrote 37 header bytes -> 37
17:39:35.903358 [0-0] == Info: [WRITE] [PAUSE] writing 37/37 bytes of type 4 -> 0
17:39:35.903619 [0-0] == Info: [WRITE] download_write header(type=4, blen=37) -> 0
17:39:35.903950 [0-0] == Info: [WRITE] client_write(type=4, len=37) -> 0
17:39:35.904207 [0-0] <= Recv header, 18 bytes (0x12)
0000: Content-Length:0
17:39:35.904494 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=18) -> 0
17:39:35.904772 [0-0] == Info: [WRITE] [OUT] wrote 18 header bytes -> 18
17:39:35.905034 [0-0] == Info: [WRITE] [PAUSE] writing 18/18 bytes of type 4 -> 0
17:39:35.905304 [0-0] == Info: [WRITE] download_write header(type=4, blen=18) -> 0
17:39:35.905459 [0-0] == Info: [WRITE] client_write(type=4, len=18) -> 0
17:39:35.905602 [0-0] <= Recv header, 60 bytes (0x3c)
0000: Content-Type: application/vnd.miele.v1+json; charset=utf-8
17:39:35.905929 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=60) -> 0
17:39:35.906235 [0-0] == Info: [WRITE] [OUT] wrote 60 header bytes -> 60
17:39:35.906444 [0-0] == Info: [WRITE] [PAUSE] writing 60/60 bytes of type 4 -> 0
17:39:35.906650 [0-0] == Info: [WRITE] download_write header(type=4, blen=60) -> 0
17:39:35.906925 [0-0] == Info: [WRITE] client_write(type=4, len=60) -> 0
17:39:35.907178 [0-0] <= Recv header, 2 bytes (0x2)
0000: 
17:39:35.907308 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=2) -> 0
17:39:35.907573 [0-0] == Info: [WRITE] [OUT] wrote 2 header bytes -> 2
17:39:35.907751 [0-0] == Info: [WRITE] [PAUSE] writing 2/2 bytes of type 4 -> 0
17:39:35.907994 [0-0] == Info: [WRITE] download_write header(type=4, blen=2) -> 0
17:39:35.908218 [0-0] == Info: [WRITE] client_write(type=4, len=2) -> 0
17:39:35.908331 [0-0] == Info: [WRITE] xfer_write_resp(len=141, eos=0) -> 0
17:39:35.908463 [0-0] == Info: [WRITE] [OUT] done
17:39:35.908648 [0-0] == Info: [READ] client_reset, clear readers
17:39:35.908888 [0-0] == Info: Connection #0 to host 172.29.18.126 left intact
157

Thanks! I observe that DOP2 works very well for your device, a lot of extra info coming out. If you’re ever interested in Remote Start, there’s a low-level script in this thread that should work for remote programming – exposing that through the server is WIP.

@bencope

I think I found the code path your device is stuck on. Try to establish a connection with this:

    groupId: "C2DB2EC520223532"
    groupKey: "4D69656C654174486F6D65496D6D65724265737365724D69656C654D69656C654D69656C654174486F6D65496D6D65724265737365724D69656C654D69656C65"

Put this in the server config, and then use the generate-summary endpoint to read the summary.

I believe your device uses this hardcoded string as an encryption key. Let me know!

158

Unfortunately that doesn’t seem to work either.

Sending HTTP request to 172.29.18.126, resourcePath=Devices
STring payload: 
83957383EFE57BBD808C042C5A4C2864D265DAEF68256F44B8840ACB22F15E4E
<Response [404]>
{'Date': 'Sat, 03 Jan 1970 12:07:38 GMT', 'Content-Length': '0', 'Content-Type': 'application/vnd.miele.v1+json; charset=utf-8'}
b''
Traceback (most recent call last):
  File "/python-docker/Server.py", line 324, in <module>
    endpoints[key]=MieleEndpointConfig(value);
                   ~~~~~~~~~~~~~~~~~~~^^^^^^^
  File "/python-docker/Server.py", line 72, in __init__
    self.autodetect_route();
    ~~~~~~~~~~~~~~~~~~~~~^^
  File "/python-docker/Server.py", line 84, in autodetect_route
    j=json.loads(response)
  File "/usr/local/lib/python3.13/json/__init__.py", line 346, in loads
    return _default_decoder.decode(s)
           ~~~~~~~~~~~~~~~~~~~~~~~^^^
  File "/usr/local/lib/python3.13/json/decoder.py", line 345, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
               ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/json/decoder.py", line 363, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
159

Found this topic and so happy it exists, the app and standard integration are a bit dissapointing and running it local is better by definition :grin:

So, I’m able to find the IP adress of my Miele but then I get stuck in the instructions. It says to run the pairing script but I cannot find it and the example on Github is empty. Could you please help me with this step?

Thanks

160

Hi,

Github wasn’t displaying the README correctly, I fixed the issue. The pairing scripts are in the helpers/ directory. Let me know if it works!