Add example `zhimi.airp.mb5` config

[cristianchelu]

I flashed my Smart Air Purifier 4 (zhimi.airp.mb5) without any issues, just a bit of soldering required, and tested the following config to be working.

There are frequent (1/s) MCU requests for the mac address which isn't implemented yet, but it doesn't seem to cause any issues.

[W][miot:291]: Unknown command 'mac'

Example log:

[19:31:45][D][miot:125]: Queuing MCU command 'get_properties 2 1 2 2 2 4 2 5 2 6 3 1 3 4 3 7 4 1 4 3 4 4 6 1 8 1 9 1 9 4 9 5 9 6 13 2 14 1'
[19:31:45][V][miot:091]: Received MCU message 'get_down'
[19:31:45][V][miot:171]: Sending reply 'down get_properties 2 1 2 2 2 4 2 5 2 6 3 1 3 4 3 7 4 1 4 3 4 4 6 1 8 1 9 1 9 4 9 5 9 6 13 2 14 1' to MCU
[19:31:45][V][miot:091]: Received MCU message 'result 2 1 0 true 2 2 0 0 2 4 0 3 2 5 0 3 2 6 0 false 3 1 0 53 3 4 0 267 3 7 0 23.600000 4 1 0 100 4 3 0 2 4 4 0 291 6 1 0 false 8 1 0 false 9 1 0 1508 9 4 0 1500 9 5 0 5 9 6 0 false 13 2 0 1 14 1 0 1'
[19:31:45][V][miot.switch:012]: MCU reported switch 2:1 is: ON
[19:31:45][V][miot.text_sensor:011]: MCU reported text sensor 2:2 is: 0
[19:31:45][V][text_sensor:013]: 'Device Fault': Received new state 0
[19:31:45][D][text_sensor:064]: 'Device Fault': Sending state 'No Faults'
[19:31:45][V][miot.select:011]: MCU reported select 2:4 is: 3
[19:31:45][D][select:015]: 'Mode': Sending state Manual (index 3)
[19:31:45][V][miot.select:011]: MCU reported select 2:5 is: 3
[19:31:45][D][select:015]: 'Fan Level': Sending state High (index 2)
[19:31:45][V][miot.switch:012]: MCU reported switch 2:6 is: OFF
[19:31:45][V][miot.sensor:011]: MCU reported sensor 3:1 is: 53.000000
[19:31:45][V][sensor:043]: 'Humidity': Received new state 53.000000
[19:31:45][D][sensor:094]: 'Humidity': Sending state 53.00000 % with 0 decimals of accuracy
[19:31:45][V][miot.sensor:011]: MCU reported sensor 3:4 is: 267.000000
[19:31:45][V][sensor:043]: 'PM2.5': Received new state 267.000000
[19:31:45][D][sensor:094]: 'PM2.5': Sending state 267.00000 µg/m³ with 0 decimals of accuracy
[19:31:45][V][miot.sensor:011]: MCU reported sensor 3:7 is: 23.600000
[19:31:45][V][sensor:043]: 'Temperature': Received new state 23.600000
[19:31:45][D][sensor:094]: 'Temperature': Sending state 23.60000 °C with 1 decimals of accuracy
[19:31:45][V][miot.sensor:011]: MCU reported sensor 4:1 is: 100.000000
[19:31:45][V][sensor:043]: 'Filter Life Level': Received new state 100.000000
[19:31:45][D][sensor:094]: 'Filter Life Level': Sending state 100.00000 % with 0 decimals of accuracy
[19:31:45][V][miot.sensor:011]: MCU reported sensor 4:3 is: 2.000000
[19:31:45][V][sensor:043]: 'Filter Use': Received new state 2.000000
[19:31:45][D][sensor:094]: 'Filter Use': Sending state 2.00000 h with 0 decimals of accuracy
[19:31:45][V][miot.sensor:011]: MCU reported sensor 4:4 is: 291.000000
[19:31:45][V][sensor:043]: 'Filter Lifetime Remaining': Received new state 291.000000
[19:31:45][D][sensor:094]: 'Filter Lifetime Remaining': Sending state 291.00000 d with 0 decimals of accuracy
[19:31:45][V][miot.switch:012]: MCU reported switch 6:1 is: OFF
[19:31:45][V][miot.switch:012]: MCU reported switch 8:1 is: OFF
[19:31:45][V][miot.sensor:011]: MCU reported sensor 9:1 is: 1508.000000
[19:31:45][V][sensor:043]: 'Motor Speed': Received new state 1508.000000
[19:31:45][D][sensor:094]: 'Motor Speed': Sending state 1508.00000 rpm with 0 decimals of accuracy
[19:31:45][V][miot.number:011]: MCU reported number 9:4 is: 1500.000000
[19:31:45][D][number:012]: 'Manual Speed': Sending state 1500.000000
[19:31:45][V][miot.number:011]: MCU reported number 9:5 is: 5.000000
[19:31:45][D][number:012]: 'Favorite Level': Sending state 5.000000
[19:31:45][V][miot.binary_sensor:012]: MCU reported sensor 9:6 is: OFF
[19:31:45][V][miot.select:011]: MCU reported select 13:2 is: 1
[19:31:45][D][select:015]: 'Display Brightness': Sending state Low (index 1)
[19:31:45][V][miot.select:011]: MCU reported select 14:1 is: 1
[19:31:45][V][miot:091]: Received MCU message 'get_down'
[19:31:45][V][miot:171]: Sending reply 'down none' to MCU
[19:31:45][V][miot:091]: Received MCU message 'get_down'
[19:31:45][V][miot:171]: Sending reply 'down none' to MCU
[19:31:45][V][miot:091]: Received MCU message 'get_down'
[19:31:45][V][miot:171]: Sending reply 'down none' to MCU
[19:31:46][V][miot:091]: Received MCU message 'mac'
[19:31:46][W][miot:291]: Unknown command 'mac'
[19:31:46][V][miot:171]: Sending reply 'ok' to MCU

Also, do you think it makes sense to include teardown / flashing instructions in this repo also, or is that better to be left to forums and other media? -- For this device, the disassembly is extremely simple once I understood the process, but managed to break 2 clips while learning it.

[dhewg]

Nice!

Any idea why the mcu would want the mac? Is there maybe something on the display that's differently now compared to the vendor fw? My 4l e.g. lets the wifi icon blink, it only stays lit until it gets the cloud answer (which is the case here once an api/mqtt clients connects)

And yes, definitely, I think it makes sense to put instruction here, let me add my 4lite to the wiki here and make up some general structure. You can then add your 4 there too.

[cristianchelu]

Absolutely no clue why it would need it. For the RFID reader? Bluetooth pairing? Allowing debug actions for a magic string mac?

Just for fun, I hardcoded the reply with my actual mac

void Miot::process_message_(char *msg) {
//...
else if (cmd == "mac") {
    send_reply_("ec4d3exxxxxx"); // redacted

and I could see no difference in behavior or display. The WiFi indicator is as you said, blinking until we reply with cloud, then stable. Even the reset filter life action works.

If we provide a reply for this, the MCU only asks for it once at startup then shuts up, otherwise spams once a second.

I'll watch out for the wiki, too, thanks!

[dhewg]

I think all radio connectivity is done by the esp, not the stm/gd mcu? Which is why I'm curious. It may be useless for a purifier, but maybe there're devices where it's differently.

Anyway, I don't think there're any concerns in telling the mcu about it.

Since you can actually test it, please add another commit for it. If only to shut it up ;)

It looks like it's as simple as send_reply_(get_mac_address().c_str() as that helper seems to return the format we want.

[cristianchelu]

Fair enough.

Your snippet works as advertised, I've added & tested the commit; MCU is happy now.

[dhewg]

Nice, thanks!

I took a look at the specs for your device, a few more questions (sorry) and then we can merge this:

Does you device have zhimi.airp.mb5 printed on there? Because I noticed there's also zhimi.airp.mb5a (but the specs look identical, probably another revision with another mcu).

There's a hidden SIID 1, see the json link on top of the device page: https://miot-spec.org/miot-spec-v2/instance?type=urn:miot-spec-v2:device:air-purifier:0000A007:zhimi-mb5:1 My 4l defines a few 1:*, but the mcu only sends 1:5. But only on power cycle, not with an esphome ota update.

Does this not work?

text_sensor:
  - platform: "miot"
    miot_siid: 1
    miot_piid: 5

Try logging while power cycling, maybe even others of 1:* are being sent? (Btw, there's a TODO in miot.cpp to reset the mcu on e.g. ota update to solve getting these values every time. I guess there's a esp gpio connected to the stm/gd reset line or something so we get trigger it, any clue how that works on your board? I haven't checked mine yet)

What about these actions?

button:
  - platform: "miot"
    miot_siid: 2
    miot_aiid: 1
    name: "Toggle Power"
    icon: mdi:power
  - platform: "miot"
    miot_siid: 9
    miot_aiid: 1
    name: "Toggle Mode"
    icon: mdi:cached
  - platform: "miot"
    miot_siid: 9
    miot_aiid: 2
    name: "Toggle Fan Level"
    icon: mdi:approximately-equal

And any idea what's up with: 9:2 bs 9:5? 9:4 vs 9:9?

And finally, is it worth adding 11:1/2/3? Looks nice to have?

[cristianchelu]

Absolutely no worries, ask as much as you want!

I got the mb5 from the other integrations (miio-auto, python-miio, etc), they all reported the same ID; This is the first I've heard of an mb5a. There's nothing in the style of zhimi.airp printed on the device, so if there's another way I can double check this, I will -- I've the official FW backed up.

Do the get_properties 1 X calls need to be the first ones out (i.e. delete most of the yaml config and only use the service mcu_command) after a power cycle or is the lockout somehow time-based?

IIRC I was interested in 11:1 purify-volume but received something like -5001 and called it a day. I'll put that and others that fail on the list to try after a power cycle.

I'll check on all of your points in the next days whenever I can spare the time and get back to you.

[dhewg]

IIRC sending get_properties on anything SIID 1 won't work, you just get an error. But the mcu sends properties_changed on 1:* upon cold boot.

For the 4l, it's just the serial number. And because of this behavior that entry has a miot_poll: false ;)

[cristianchelu]

From the 1:* batch I also seem to only get the serial number (1:5). Although, funnily enough, the factory forgot to burn mine in and the flurry of \xffs crashes my HA instance on repeat. I'm not sure where to report that.

[22:41:52][V][miot:091]: Received MCU message 'properties_changed 2 1 true 2 5 3 2 4 3 3 4 20 3 1 47 3 7 24.5 4 1 100 4 3 28 4 4 290 6 1 false 8 1 false 2 6 false 13 2 1 9 5 6 9 9 3 12 1 "81:73:bb:xx:xx:xx:xx" 1 5 "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"'
[22:41:52][V][miot.switch:012]: MCU reported switch 2:1 is: ON
[22:41:52][D][switch:055]: 'Power': Sending state ON
[22:41:52][V][miot.select:011]: MCU reported select 2:5 is: 3
[22:41:52][D][select:015]: 'Fan Level': Sending state High (index 2)
[22:41:52][V][miot.select:011]: MCU reported select 2:4 is: 3
[22:41:52][D][select:015]: 'Mode': Sending state Manual (index 3)
[22:41:52][V][miot.sensor:011]: MCU reported sensor 3:4 is: 20.000000
[22:41:52][V][sensor:043]: 'PM2.5': Received new state 20.000000
[22:41:52][D][sensor:094]: 'PM2.5': Sending state 20.00000 µg/m³ with 0 decimals of accuracy
[22:41:52][V][miot.sensor:011]: MCU reported sensor 3:1 is: 47.000000
[22:41:52][V][sensor:043]: 'Humidity': Received new state 47.000000
[22:41:52][D][sensor:094]: 'Humidity': Sending state 47.00000 % with 0 decimals of accuracy
[22:41:52][V][miot.sensor:011]: MCU reported sensor 3:7 is: 24.500000
[22:41:52][V][sensor:043]: 'Temperature': Received new state 24.500000
[22:41:52][D][sensor:094]: 'Temperature': Sending state 24.50000 °C with 1 decimals of accuracy
[22:41:52][V][miot.sensor:011]: MCU reported sensor 4:1 is: 100.000000
[22:41:52][V][sensor:043]: 'Filter Life Level': Received new state 100.000000
[22:41:52][D][sensor:094]: 'Filter Life Level': Sending state 100.00000 % with 0 decimals of accuracy
[22:41:52][V][miot.sensor:011]: MCU reported sensor 4:3 is: 28.000000
[22:41:52][V][sensor:043]: 'Filter Use': Received new state 28.000000
[22:41:52][D][sensor:094]: 'Filter Use': Sending state 28.00000 h with 0 decimals of accuracy
[22:41:52][V][miot.sensor:011]: MCU reported sensor 4:4 is: 290.000000
[22:41:52][V][sensor:043]: 'Filter Lifetime Remaining': Received new state 290.000000
[22:41:52][D][sensor:094]: 'Filter Lifetime Remaining': Sending state 290.00000 d with 0 decimals of accuracy
[22:41:52][V][miot.switch:012]: MCU reported switch 6:1 is: OFF
[22:41:52][D][switch:055]: 'Notification Sounds': Sending state OFF
[22:41:52][V][miot.switch:012]: MCU reported switch 8:1 is: OFF
[22:41:52][D][switch:055]: 'Child Lock': Sending state OFF
[22:41:52][V][miot.switch:012]: MCU reported switch 2:6 is: OFF
[22:41:52][D][switch:055]: 'Ionizer': Sending state OFF
[22:41:52][V][miot.select:011]: MCU reported select 13:2 is: 1
[22:41:52][D][select:015]: 'Display Brightness': Sending state Low (index 1)
[22:41:52][V][miot.number:011]: MCU reported number 9:5 is: 6.000000
[22:41:52][D][number:012]: 'Favorite Level': Sending state 6.000000
[22:41:52][W][miot:183]: Received property value without component: 9 9 3
[22:41:52][W][miot:183]: Received property value without component: 12 1 81:73:bb:xx:xx:xx:xx
[22:41:52][V][miot.text_sensor:011]: MCU reported text sensor 1:5 is: \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
[22:41:52][V][text_sensor:013]: 'Serial Number': Received new state \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
[22:41:52][D][text_sensor:064]: 'Serial Number': Sending state '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'

I've tried

  - platform: "miot"
    miot_siid: 1
    miot_piid: 5
    miot_poll: false
    name: "Serial Model"
    entity_category: diagnostic
    filters:
      - substitute:
        - "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff -> No Data"

But this still doesn't prevent my HA from crashing, most likely on account of missing escapes on \ or some other part of the documentation I'm missing, so I've left it out for now.

---

The properties_changed message is sent on my device on OTA update also, no power cycle needed, and no change when power cycling. See above logs.

---

The toggles bascially do what it says on the tin. Toggle Power goes on ~ off ~ on ~ off on the power switch; Toggle Mode goes Auto ~ Sleep ~ Favourite ~ Manual; Toggle Fan Level goes 1 ~ 2 ~ 3. I'd much rather have the selects instead, and people with a real use for them can easily add them.

---

I didn't find any GPIOs connected on the ESP32 other than for UART.

---

The 9s are basically synonyms for other controls. 9:9 controls the fan speed levels in 2:5 within 3 settings, but doesn't offer as much control as 9:4, which can do the full 450-2000rpm spectrum. Changing 2:5 also updates 9:9.

Favourite Level 9:5 and Favourite Speed 9:2 control the level preference when switching to Favourite mode, but don't immediately switch to it. Changing one updates the other on next poll. I've added "Favourite Speed" as the preferred (finer control) choice.

---

11:(1-3) seem interesting to have, yes. I've added Total Purify Volume to the config, it's working now, I don't know what I did wrong previously. Also added Average AQI, seems fun.

I didn't add 11:3 AQI, because it doesn't update in real-time, only on poll (currently 1 minute). PM2.5 sensor does get notifies from MCU frequently, and AQI can be derived off of that in HA.

---

If there's anything I missed, let me know; it's been quite a checkup :smile:

[cristianchelu]

Screenshots of config.

Note: Purifier Energy (kWh) and Purifier Power (W) are part of the Powercalc custom integration, and not this config, I've measured the consumption with a Kill-a-Watt and fitted the consumption curve based on RPM to get an approximation of consumption. Though... now that the ESP32 is liberated, who knows what hardware add-ons are possible! :sunglasses:

[dhewg]

Okay, thanks for checking all that! While the lack of details won't stop me from merging this, it's good to know as other devices probably have similar properties.

For the serial, we can just leave it out, but the escaping issue might be a yaml thing, where you may have to use single instead of double quotes or something. But even with that useless value, it's probably worth reporting the crash to HA.

If I read that correctly the favorite speed now matches the manual speed, so you have two modes behaving exactly the same, kinda making one useless. I'd just add both and let users chose what fits their bill.

On that note, I'd add the power and mode toggle to the config too. A use case would be a remote that uses the toggles upon pressing a button.

As additional controls are just visible in the device settings, and you can exclude anything you don't want on lovelace cards, so I'd tend to add everything and let each user decide what they want to use. That's easier than letting every other user hunt down stuff from the specs. But having said that, I can just add the missing ones

[dhewg]

Merged, thanks! I'm unifying the configs, why'd you put into speed/volume/aqi into entity_category: diagnostic? I'd argue they're more like sensors?

[cristianchelu]

I didn't think it through very much, to be honest. You can move them into whichever category you see fit or makes more sense, I'm keeping my local copy as it is :D

If you're merging them, maybe it also makes sense to add:

button:
  - platform: "miot"
    miot_siid: 4
    miot_aiid: 1
+   miot_action_args: '3 0'
    name: "Reset Filter Life"
    icon: mdi:restart
    entity_category: config

See my comment on the other issue here

[dhewg]

Yeah, already added :) And I think your favorite speed is off?

@@ -140,8 +154,8 @@ number:
     miot_piid: 2
     name: "Favorite Speed"
     icon: mdi:speedometer
-    min_value: 0
-    max_value: 2000
+    min_value: 200
+    max_value: 2300
     step: 1
   - platform: "miot"
     miot_siid: 9

[cristianchelu]

Oh, I forgot about that. Actually that one should be 450 - 2000. That's the only speed range it accepts for any mode, even with the official firmware.

[dhewg]

Huh, alright... I commited some changes so all 3 devices are unified where possible. I took some chunks of yours for the other two and vice versa. Let me know if I messed something up ;)

[cristianchelu]

Just minor things.

I took the favorite/manual levels for a spin also, and realized they don't accept 0, just 1-11.

While reading the docs I realized that substitute does a global search&replace, so a status 10 might translate to "PM2.5 Sensor ErrorNo Faults", and the map filter only considers the whole state string.

I didn't create a PR because I don't know if you'll like my serial number solution. The ESPHome subtitution/map filters don't know about escaping characters from what I've read, but the lambda works, and the extra map filter is just to make it pretty.

I was also thinking about miot_action_args: "3 0" (Param 3 w/ value 0), instead of an implied miot_action_args: "3 undefined" in case other FWs don't fill that in for you.

diff --git a/config/zhimi.airp.mb5.yaml b/config/zhimi.airp.mb5.yaml
index b5bae00..ea5151e 100644
--- a/config/zhimi.airp.mb5.yaml
+++ b/config/zhimi.airp.mb5.yaml
@@ -128,14 +128,20 @@ select:
       2: "Fahrenheit"

 text_sensor:
-# TODO while this gets sent, it may be 20 times escaped 0xff, which makes HA crash
-#  - platform: "miot"
-#    miot_siid: 1
-#    miot_piid: 5
-#    miot_poll: false
-#    name: "Serial Number"
-#    icon: mdi:numeric
-#    entity_category: diagnostic
+  # TODO while this gets sent, it may be 20 times escaped 0xff, which makes HA crash
+  - platform: "miot"
+    miot_siid: 1
+    miot_piid: 5
+    miot_poll: false
+    name: "Serial Number"
+    icon: mdi:numeric
+    entity_category: diagnostic
+    filters:
+      - lambda: |-
+          std::replace(x.begin(), x.end(),'\xff','-');
+          return x;
+      - map:
+        - '-------------------- -> Not set'
   - platform: "miot"
     miot_siid: 2
     miot_piid: 2
@@ -143,12 +149,12 @@ text_sensor:
     icon: mdi:fan-alert
     entity_category: diagnostic
     filters:
-      - substitute:
-        - "0 -> "
-        - "1 -> PM2.5 Sensor Error"
-        - "2 -> Temperature Error"
-        - "3 -> Humidity Error"
-        - "4 -> No Filter Detected"
+      - map:
+        - 0 -> No Faults
+        - 1 -> PM2.5 Sensor Error
+        - 2 -> Temperature Error
+        - 3 -> Humidity Error
+        - 4 -> No Filter Detected

 number:
   - platform: "miot"
@@ -165,7 +171,7 @@ number:
     miot_piid: 4
     name: "Manual Speed"
     icon: mdi:speedometer
-    min_value: 0
+    min_value: 450
     max_value: 2000
     step: 1
   - platform: "miot"
@@ -173,7 +179,7 @@ number:
     miot_piid: 5
     name: "Favorite Level"
     icon: mdi:speedometer
-    min_value: 0
+    min_value: 1
     max_value: 11
     step: 1
   - platform: "miot"
@@ -181,7 +187,7 @@ number:
     miot_piid: 9
     name: "Manual Level"
     icon: mdi:speedometer
-    min_value: 0
+    min_value: 1
     max_value: 11
     step: 1

@@ -255,7 +261,7 @@ button:
   - platform: "miot"
     miot_siid: 4
     miot_aiid: 1
-    miot_action_args: "3"
+    miot_action_args: "3 0"
     name: "Reset Filter Life"
     icon: mdi:restart
     entity_category: config

[dhewg]

I'll look into string decoding later, \x00 certainly looks like a hex encoded unprintable char (but the serial docs just mention \u0000). That may be required in the long term anyway.

The map thing looks good, but now we need to change all configs :)

I could have sworn I changed the filter reset to 3 0 already, but I probably messed up a rebase.

Let's leave the serial number out for now, if you want you can add a PR for the rest for proper commit credits, else I'll do it, I don't care either way :) If you do, please split that into two commits, one for the global map things, and another for the fixed values.

[dhewg]

I'm completely fishing in the dark here, so this might crash and burn, but does this properly decode the hex values? hex.patch.txt It should decode anything that's unprintable to ?

[dhewg]

I've created a simple wiki page for my 4lite, if you want you could create one for your device. Admittedly I just quickly dumped some infos there, maybe we should use github pages instead?

[cristianchelu]

Unfortunately that doesn't change anything with the committed config serial number block uncommented.

[20:35:34][D][text_sensor:064]: 'Serial Number': Sending state '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
[20:35:34][W][component:214]: Component miot took a long time for an operation (0.10 s).
[20:35:34][W][component:215]: Components should block for at most 20-30ms.
[20:35:34][W][api.connection:104]: Home Assistant 2024.2.0b11 (192.168.100.2): Connection closed
[20:35:34][D][api:102]: Accepted 192.168.100.2
[20:35:34][W][component:214]: Component api took a long time for an operation (0.06 s).
[20:35:34][W][component:215]: Components should block for at most 20-30ms.
[20:35:34][D][api.connection:1121]: Home Assistant 2024.2.0b11 (192.168.100.2): Connected successfully
[20:35:35][W][api.connection:102]: Home Assistant 2024.2.0b11 (192.168.100.2): Connection reset
[20:35:35][D][api:102]: Accepted 192.168.100.2

I'll add my disassembly / flash instructions to the wiki. After reading yours, I realized I could have also flashed mine without soldering :D -- I was concerned about flaky connections when just jamming the DuPont connections there, but hey, if it works it works!

[dhewg]

Bummer, did you get the Decoding hex value messages when the mcu sends the serial? If you did, I indeed messed up the patch, fixed version: 0001-XXX-hex.patch.txt If you didn't, that ^ patch won't fix it either.

[cristianchelu]

D'oh! I was on DEBUG. Tried the new patch in any case and sure enough, it didn't fix it either.

[21:09:13][V][miot.text_sensor:011]: MCU reported text sensor 1:5 is: \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
[21:09:13][V][text_sensor:013]: 'Serial Number': Received new state \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
[21:09:13][D][text_sensor:064]: 'Serial Number': Sending state '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
[21:09:13][V][miot:181]: Sending reply 'ok' to MCU
[21:09:13][V][miot:091]: Received MCU message 'get_down'
[21:09:13][V][miot:181]: Sending reply 'down none' to MCU
[21:09:13][V][miot:091]: Received MCU message 'get_down'
[21:09:13][V][miot:181]: Sending reply 'down none' to MCU
[21:09:13][W][component:214]: Component miot took a long time for an operation (0.28 s).
[21:09:13][W][component:215]: Components should block for at most 20-30ms.
[21:09:13][V][miot:091]: Received MCU message 'get_down'
[21:09:13][V][miot:181]: Sending reply 'down none' to MCU
[21:09:13][W][api.connection:104]: Home Assistant 2024.2.0b11 (192.168.100.2): Connection closed
[21:09:13][V][api:115]: Removing connection to Home Assistant 2024.2.0b11
[21:09:13][V][miot:091]: Received MCU message 'get_down'
[21:09:13][V][miot:181]: Sending reply 'down none' to MCU
[21:09:13][D][api:102]: Accepted 192.168.100.2

[dhewg]

They few lines above that also didn't contain the mentioned debug line?

[cristianchelu]

I disabled the text sensor to stop it having a seizure, but this log should have passed through your patch too anyway:

[21:10:25][V][miot:091]: Received MCU message 'get_down'
[21:10:25][V][miot:181]: Sending reply 'down none' to MCU
[21:10:25][V][miot:091]: Received MCU message 'properties_changed 2 1 true 2 5 3 2 4 0 3 4 316 3 1 48 3 7 24.1 4 1 100 4 3 37 4 4 290 6 1 false 8 1 false 2 6 false 13 2 1 9 5 0 9 9 2 12 1 "81:73:bb:xx:xx:xx:xx" 1 5 "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"'
[21:10:25][V][miot.switch:012]: MCU reported switch 2:1 is: ON
[21:10:25][D][switch:055]: 'Power': Sending state ON
[21:10:25][V][miot.select:011]: MCU reported select 2:5 is: 3
[21:10:25][D][select:015]: 'Fan Level': Sending state High (index 2)
[21:10:25][V][miot.select:011]: MCU reported select 2:4 is: 0
[21:10:25][D][select:015]: 'Mode': Sending state Auto (index 0)
[21:10:25][V][miot.sensor:011]: MCU reported sensor 3:4 is: 316.000000
[21:10:25][V][sensor:043]: 'PM2.5': Received new state 316.000000
[21:10:25][D][sensor:094]: 'PM2.5': Sending state 316.00000 µg/m³ with 0 decimals of accuracy
[21:10:25][V][miot.sensor:011]: MCU reported sensor 3:1 is: 48.000000
[21:10:25][V][sensor:043]: 'Humidity': Received new state 48.000000
[21:10:25][D][sensor:094]: 'Humidity': Sending state 48.00000 % with 0 decimals of accuracy
[21:10:25][V][miot.sensor:011]: MCU reported sensor 3:7 is: 24.100000
[21:10:25][V][sensor:043]: 'Temperature': Received new state 24.100000
[21:10:25][D][sensor:094]: 'Temperature': Sending state 24.10000 °C with 1 decimals of accuracy
[21:10:25][V][miot.sensor:011]: MCU reported sensor 4:1 is: 100.000000
[21:10:25][V][sensor:043]: 'Filter Life Level': Received new state 100.000000
[21:10:25][D][sensor:094]: 'Filter Life Level': Sending state 100.00000 % with 0 decimals of accuracy
[21:10:25][V][miot.sensor:011]: MCU reported sensor 4:3 is: 37.000000
[21:10:25][V][sensor:043]: 'Filter Used Time': Received new state 37.000000
[21:10:25][D][sensor:094]: 'Filter Used Time': Sending state 37.00000 h with 0 decimals of accuracy
[21:10:25][V][miot.sensor:011]: MCU reported sensor 4:4 is: 290.000000
[21:10:25][V][sensor:043]: 'Filter Lifetime Remaining': Received new state 290.000000
[21:10:25][D][sensor:094]: 'Filter Lifetime Remaining': Sending state 290.00000 d with 0 decimals of accuracy
[21:10:25][V][miot.switch:012]: MCU reported switch 6:1 is: OFF
[21:10:25][D][switch:055]: 'Notification Sounds': Sending state OFF
[21:10:25][V][miot.switch:012]: MCU reported switch 8:1 is: OFF
[21:10:25][D][switch:055]: 'Child Lock': Sending state OFF
[21:10:25][V][miot.switch:012]: MCU reported switch 2:6 is: OFF
[21:10:25][D][switch:055]: 'Ionizer': Sending state OFF
[21:10:25][V][miot.select:011]: MCU reported select 13:2 is: 1
[21:10:25][D][select:015]: 'Display Brightness': Sending state Low (index 1)
[21:10:25][W][miot:193]: Received property value without component: 9 5 0
[21:10:25][W][miot:193]: Received property value without component: 9 9 2
[21:10:25][W][miot:193]: Received property value without component: 12 1 81:73:bb:xx:xx:xx:xx
[21:10:25][W][miot:193]: Received property value without component: 1 5 \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
[21:10:25][V][miot:181]: Sending reply 'ok' to MCU
[21:10:25][V][miot:091]: Received MCU message 'get_down'
[21:10:25][V][miot:181]: Sending reply 'down none' to MCU
[21:10:25][V][miot:091]: Received MCU message 'get_down'
[21:10:25][V][miot:181]: Sending reply 'down none' to MCU
[21:10:25][W][component:214]: Component miot took a long time for an operation (0.27 s).
[21:10:25][W][component:215]: Components should block for at most 20-30ms.
[21:10:25][V][miot:091]: Received MCU message 'get_down'
[21:10:25][V][miot:181]: Sending reply 'down none' to MCU

[dhewg]

It's probably something silly, yet I'm not seeing it, but that might be the whiskey. I'll try again tomorrow ;)

[cristianchelu]

Enjoy the whiskey and don't stress about this. I'll create an issue in the meantime so we can better track the discussions and not beat this poor PR too much more.

In either case it's a corner case issue for a corner case feature :grin:

:tumbler_glass: :tumbler_glass:.

[dhewg]

Copy that, thanks :)

[dhewg]

As always, the probable reason appears right after dropping it...

It may just be the logging function which encodes unprintable chars. I think there might be a 0xff char in the string already, and not a hex encoded string in the form of \xff.

How about this? really.txt

[cristianchelu]

You just couldn't leave it, could you?

[21:57:46][W][miot:186]: Received property value without component: 1 5 ????????????????????
[21:57:46][V][miot:174]: Sending reply 'ok' to MCU

:heavy_check_mark:

[dhewg]

Sorry, nice & cheers! :D