Thats a good tear down.

I tried something similar with a set of LED lights I bought from amazon, but the commands I sent the device appeared to brick it. The controller never booted again after sending it a simple TCP packet. I dont think it was smart enough to be protected, I have a feeling I managed to put it into bootloader mode or something.

Hi! Creator of the pyhuum library and the Huum integration here. If you need someone else to double-check anything, please let me know. I would be more than happy to help out here, as the current API approach is not ideal.

Some things that bother me regarding the current integration are that their API does not return the set value of the sauna unless it is on, nor does it return the target value of the sauna unless it is on. However, they do have this information, as one can circumvent this limitation by turning off the sauna, and then it will return these values. I talked to their CTO about this, and it seems like they don't want to spam the sauna with requests all the time; this is the reason the status endpoint does not return this value. In the end, one can get around this, and now the library spams two requests if the sauna is off: first to check if the sauna is on, and if it is not, then we call the "off" endpoint and get the correct value. This all leads to some unexpected behavior as well, since the status of the sauna does not update fast enough, causing the sauna to turn off after it has been turned on at times. This is not a problem when used exclusively with Home Assistant, as it keeps internal state, but it can be annoying when it is used via the physical controls in combination with HA.

You can find my contact info in the pyhuum package if you want to discuss anything.