search

rospogrigio / airbnk_mqtt

MQTT control of Airbnk locks.
GNU General Public License v3.0
27 stars 6 forks source link

ESPHome #24

Open formatBCE opened 1 year ago

formatBCE commented 1 year ago

Hi @rospogrigio ! Long time :)

I recently developed custom BLE presence for HA, based on ESP32, and meanwhile realized, how to get it working as custom ESPHome component. Do you think it's worth to move my custom gateway firmware to similar component? It would require 1 file and 6 lines of code to add it.

I actually think, that it would be useful for new users. Tasmota is good enough, but ESPHome is widely used with HA. E.g. someone could install this to SONOFF NS Panel. :)

rospogrigio commented 1 year ago

Sounds interesting but I'm not sure I am understanding this fully, especially because I don't know much about ESPHome, can you add some more details to explain, and pros and cons of the thing? Thank you!

formatBCE commented 1 year ago

Well, ESPHome allows to have ESP configuration and updates at one place, and it's really convenient to create firmware, flash it, track devices, read logs, OTA update etc.

Custom components to ESPHome are C++ .h files, that basically can use esphome.h library, and be included into ESPHome configuration.

For example, check corresponding section in my BLE presence repo here

rospogrigio commented 1 year ago

Well, looks promising, let's try it! Will we need to change anything in the integration?

formatBCE commented 1 year ago

Cool, I will try it in my setup and let you know.

hometheater13 commented 1 year ago

Hi @formatBCE , @rospogrigio

It possible to add also fingerprint and keypad example for sensor battery ?

thx for all . BR Emil

rospogrigio commented 1 year ago

It possible to add also fingerprint and keypad example for sensor battery ?

Sorry I don't understand your question, can you explain more clearly? Thank you

hometheater13 commented 1 year ago

image for this lock they also have pinpad and keypad that working with bluetooth also and connecting with the same app - WeHere it will be great to add them inside to monitor their battery status and who loged in . thx

rospogrigio commented 1 year ago

Well then I believe it's not possible (I own the fingerprint command too), I believe that the ESP32 can connect to one device at a time but @formatBCE might correct me. In any case, I believe that they communicate with a protocol different form the lock's one... I think all the effort is not worth it, only for checking the battery level.

hometheater13 commented 1 year ago

Ok , thx for quick response.

On Sun, 4 Sept 2022, 15:43 rospogrigio, @.***> wrote:

Well then I believe it's not possible (I own the fingerprint command too), I believe that the ESP32 can connect to one device at a time but @formatBCE https://github.com/formatBCE might correct me. In any case, I believe that they communicate with a protocol different form the lock's one... I think all the effort is not worth it, only for checking the battery level.

— Reply to this email directly, view it on GitHub https://github.com/rospogrigio/airbnk_mqtt/issues/24#issuecomment-1236332423, or unsubscribe https://github.com/notifications/unsubscribe-auth/APONFSXIIWL7WKRMJXDX423V4SKN5ANCNFSM6AAAAAAQAANSSQ . You are receiving this because you commented.Message ID: @.***>

formatBCE commented 1 year ago

@rospogrigio hello! Working for 15 minutes a week (kids...), I think I have somewhat working custom gateway component, which can be installed with ESPHome.

In parallel (having convenient logging, provided by ESPHome), I discovered problem with gateway itself. It's not so visible on custom firmware, but on ESPHome I clearly see it.

Case is, that on ESP32 antenna is used by WiFi and BLE simultaneously. While simply scanning, it's managed by scan window and interval params (basically, BLE is using antenna for 64 ms, and then releases it for 64ms for WiFi).

But with commands it's different story: for sending command to lock, gateway should establish connection to device, service and characteristic to write data. Then gateway should get back write status to report back to MQTT. This takes time, and WiFi does sometimes disconnect (especially if first connect try was unsuccessful, and we're retrying). Then after writing data, gateway tries to send status to MQTT. Which is impossible actually because WiFi is reconnecting. So this answer might be lost.

I temporarily patched it by adding MQTT connection check on status sending, but main problem persists: ESP32 isn't created for simultaneous extensive usage of BT and WiFi.

My main topic here is following:

Think about it. Worth it?

rospogrigio commented 1 year ago

OK that looks interesting and explains some realiability issues. I don't understand the 2 final questions though:

Also, how long does the handshakes take, in terms of ms? And how about the 64ms slots, are they defined by the firmware?

formatBCE commented 1 year ago

Sorry for being unclear here. Yes, I'd like to check possibility to move payload generation to ESP. It would help to loose coupling between HA and ESP, easing status tracking and handling errors (basically, HA integration would be responsible only on setup/interface part).

That window of 64 ms (as well as interval of 128 ms) is fully customizable. But don't focus on this, as that part (scan) works perfectly now. What is giving problems, is command execution (it's a bit different from passive scan). However, yesterday I drastically optimized that part (and also published custom component for ESPHome setup). Didn't do it for main firmware yet (there's different code base because of ESPHome API), but on ESPHome gateway I did like 20 consecutive lock/unlock operations, and they all passed without error. So I consider this mitigated (though not fixed). Handshake/connection is pretty fast, unless there's intermittent error connecting, when we're retrying. Also additional time is needed to read from that status characteristic after writing (it almost always takes 3-4 tries with 700 ms in between) because of that ...00000 value, you remember.

Do we actually need it btw? If ESP just sends success, won't it be enough? It could help drastically, if we skip that. As I see, you're using only adv data for codes generation - but you will receive that in next scan.

rospogrigio commented 1 year ago

Yeah I questioned myself many times about this. One issue could be if the meanwhile it receives a command via the app, but we probably can consider this event as very unlikely. I seem to remember that actually the lock would not accept further commands until that status characteristic is updated but I could be very wrong in this remembrance. The only thing we actually need from that status is the lockEvents as you know, but it could just be incremented on successful commands... I suggest you try removing it and see if it works or you get any issues.

formatBCE commented 1 year ago

I would have to remove it from integration too, right? Because there's logic, that will fail operation result, if there's no correct response from characteristic.

What about lockEvents - isn't it gets updated on each advertisement message? I see it in code.

I will try to remove this logic from gateway and integration and check result.

formatBCE commented 1 year ago

Ok, i removed need of status payload from integration, and disabled reading from characteristic in gateway. From my feeling, it works WAY better. Status of lock is updated with next advertisement, and consecutive commands are working good. There's a bit more work on synchronizing state in HA, but overall it's really good. Now it's lagging only, if lock is lagging itself (reconnections).

P.S. Will use it like this for some time to ensure it's all good, and maybe post PR.

formatBCE commented 1 year ago

@rospogrigio today I realized, that payload shouldn't be generated on ESP, because for this sensitive fields, used for generation, will have to be transferred over MQTT from HA integration - and this should be considered insecure channel. So I guess we must leave it like this.

rospogrigio commented 1 year ago

Well, I understand your point but we can think about this. I have always felt a bit of paranoia around this because I believe the risk is extremely low, because in this case to gain access to your house an attacker should:

On top of that, I believe that the keys should be sent to the gateway only at its startup, so he should intercept the codes right at that moment because they would not be exchanged in any other moment. If you still feel this to be a bit too risky, maybe it's possible to use one of these methods to send the keys to the lock in a secure way: 1) make the user store them within the web configuration of the gateway, and have the keys stored in the configuration write-only. To increase this method's security however the configuration should run over HTTPS and I don't know if it's easy/feasible 2) maybe it's possible to generate a pair of public/private RSA keys on the gateway and encrypt the keys before sending them to the gateway?

Just a couple of ideas that came into my mind, let me know what you think... Great job in the meantime! 👍

formatBCE commented 1 year ago

Thanks for suggestions! Today i found that BLE library for ESP32 allows continuous scanning instead of restarting all the time we received adv from lock. It allows to send each and every adv message to HA, which results on lightning-fast status update. Testing on my setup and have no problems yet.

About my security concerns - i'm assuming that some users can use insecure MQTT (e.g. public MQTT servers) - and this can lead to exposure. After that, possible intruder just have to bring device with gateway firmware to the door, that's it.

On the other hand, with current setup the only thing that can be catched on MQTT is one-time command, which won't help breaking in.

I understand, that actual burglar would just kick the door or window out, but don't want to add another way to get long-term backdoor to the lock (which actually could be untraceable).

On adding config to gateway - yes, it can be done, e.g., on ESPHome config step, from secrets file. However, i don't see good way to get that values without scraping debug logs.

Encryption would work, i guess, but it would add more complication to message handling, and slow down operation drastically (ESP chip is not for encryption all-in-all) :)

I was already thinking on getting everything, including API calls, to the gateway. This way everything would be bound to ESP exclusively. Don't know if it's worth trying though. It's a heck of work :)

I'd like to know, if we're ready to get rid of status characteristic. I removed related code from my installation, and it works stable and reliable.

formatBCE commented 1 year ago

Just to share my excitement: I just successfully merged two of my ESP BLE projects into one ESPHome-based component, and installed to one ESP32. Also i did install this to Sonoff NSPanel, which is conveniently located right beside my front door, so it will be both picking up my Tile beacons on approach, and rule my lock :)

rospogrigio commented 1 year ago

I'd like to know, if we're ready to get rid of status characteristic. I removed related code from my installation, and it works stable and reliable.

Well, try it yourself and then you can submit a PR. I'm not sure I followed everything you've been trying but if you have something to share I'd be happy to try it on my setup and provide feedback. Let me know! 👍

rospogrigio commented 1 year ago

Hi @formatBCE , I'd need your help... I had moved to the ESPHome-based component as you suggested, and everything was working quite fine. Now, I have upgraded my RPi 4 to Debian bullseye (which was a huge struggle, but I finally managed to upgrade everything), and everything is working.... except for the airbnk. The ESPHome logs keep saying:

[16:04:02][D][airbnk_mqtt:123]: Sending adv
[16:04:04][I][mqtt:176]: Connecting to MQTT...
[16:04:04][W][mqtt:264]: MQTT Disconnected: TCP disconnected.
[16:04:04][D][airbnk_mqtt:105]: BLE scan heartbeat
[16:04:05][D][airbnk_mqtt:123]: Sending adv
[16:04:06][D][airbnk_mqtt:123]: Sending adv
[16:04:09][D][airbnk_mqtt:123]: Sending adv
[16:04:09][I][mqtt:176]: Connecting to MQTT...
[16:04:09][W][mqtt:264]: MQTT Disconnected: TCP disconnected.
[16:04:10][D][airbnk_mqtt:105]: BLE scan heartbeat
[16:04:11][D][airbnk_mqtt:123]: Sending adv
[16:04:12][D][airbnk_mqtt:123]: Sending adv

The mosquitto instead logs:

1667744264: mosquitto version 2.0.11 running
1667744462: New connection from ::1:44493 on port 1883.
1667744462: New client connected from ::1:44493 as 1F9uyNVRPBN6z1KR6doZqb (p2, c1, k60, u'airbnk_mqtt').
1667744923: Client 1F9uyNVRPBN6z1KR6doZqb closed its connection.
1667745021: New connection from ::1:55317 on port 1883.
1667745021: New client connected from ::1:55317 as 5YpDtxFU3zLDOiiGmk74qH (p2, c1, k60, u'airbnk_mqtt').
1667745431: Client 5YpDtxFU3zLDOiiGmk74qH closed its connection.
1667745591: New connection from ::1:48367 on port 1883.
1667745591: New client connected from ::1:48367 as 3nE0vFsPmNrAvGi3SblAmO (p2, c1, k60, u'airbnk_mqtt').
1667745787: mosquitto version 2.0.11 terminating
1667745787: Saving in-memory database to /var/lib/mosquitto//mosquitto.db.
1667745877: mosquitto version 2.0.11 starting
1667745877: Config loaded from /etc/mosquitto/mosquitto.conf.

Can you help me understand what's going on and how I can solve these issues? Thank you in advance...

formatBCE commented 1 year ago

Hi @rospogrigio !

Huh, that's tricky one. Without context, I'd say that ESP is dropping TCP connection because of conflict with BLE, and would ask to try different ESP... But, obviously, you're using same chip, as with old rPi OS, right?

Did you maybe update ESPHome to latest version, and upgraded ESP with it?

My gateway is still on ESPHome 2022.10.0, although there's update to 2022.10.2 available, and they made some BLE stack update there. Probably, it could conflict somehow...

For now it looks to me like gateway problem, not the rPi.

If you eager to play with it a bit, I suggest to:

Please let me know, if something of that works. :) Meanwhile, I won't be upgrading to 2022.10.2...

rospogrigio commented 1 year ago

Mmm I believe I did update that. How can I check the installed version? And how can I rollback?

formatBCE commented 1 year ago

Looks like there's no good way to do it - only with rollback from backup... But now we know at least, that this is possible trouble.

I'll try to update to 2022.10.2, and we'll see, of it's working for me.

formatBCE commented 1 year ago

So I updated gateway (rather flashed another chip) with 2022.10.2. It works. I had one message about TCP disconnected, but it recovered right away, and not seen after several reboots.

rospogrigio commented 1 year ago

Gosh! So what can I try to debug it? Any suggestions? Edit: can you post here what your ESPHome log is displaying? I can't remember what I'm supposed to see there, so I can't understand if it's not talking to the lock or if it's not sending data to the broker... thank you

formatBCE commented 1 year ago

As I suggested, could you put custom firmware to ESP, and try? The logic there is same, so we could test, if it's MQTT dropping connection, or ESPHome does bad thing.

rospogrigio commented 1 year ago

OK I'll try it, let's see what happens 👍

rospogrigio commented 1 year ago

OK, flashed... no luck. Here are the logs I get via serial on the ESP32:

[00:56:20]Connecting to MQTT
[00:56:20]Disconnected from MQTT.
[00:56:20]Starting MQTT reconnect timer
[00:56:20]restarted
[00:56:21]Scanning done.Error sending telemetry
[00:56:21]Scanning...   
[00:56:21]Cannot report: mqtt disconnected
[00:56:21]Time remaining: 895
[00:56:21]Cannot report: mqtt disconnected
[00:56:21]Time remaining: 644
[00:56:22]Connecting to MQTT
[00:56:22]Disconnected from MQTT.
[00:56:22]Too many retries. Restarting.
[00:56:22][WiFi-event] event: 3
[00:56:22]STA Stop
[00:56:22]ets Jun  8 2016 00:22:57
[00:56:22]
[00:56:22]rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[00:56:22]configsip: 0, SPIWP:0xee
[00:56:22]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[00:56:22]mode:DIO, clock div:2
[00:56:22]load:0x3fff0030,len:1184
[00:56:22]load:0x40078000,len:12784
[00:56:22]load:0x40080400,len:3032
[00:56:22]entry 0x400805e4
[00:56:22]Connecting to WiFi...
[00:56:22][WiFi-event] event: 0
[00:56:22]Wifi Ready
[00:56:22][WiFi-event] event: 2
[00:56:22]STA Start
[00:56:22]WiFi Timer is inactive; resetting 
[00:56:23]restarted
[00:56:23]restarted
[00:56:25][WiFi-event] event: 4
[00:56:25]Connecting to WiFi...
[00:56:25][WiFi-event] event: 5
[00:56:25]WiFi lost connection, resetting timer 
[00:56:25]restarted
[00:56:27][WiFi-event] event: 4
[00:56:27][WiFi-event] event: 7
[00:56:27]IP address:   192.168.1.10
[00:56:27]Hostname:     airbnk_topic          (I believe this is a bug, this is actually the name of the topic)
[00:56:27]Connecting to MQTT
[00:56:27]Scanning...   
[00:56:27]Stopping wifi reconnect timer
[00:56:27]Cannot report: mqtt disconnected
[00:56:27]Starting MQTT reconnect timer
[00:56:27]restarted
[00:56:27]Cannot report: mqtt disconnected
[00:56:27]Starting MQTT reconnect timer
[00:56:27]restarted
[00:56:27]Disconnected from MQTT.
[...]
[00:56:36]Cannot report: mqtt disconnected
[00:56:36]Time remaining: 1516
[00:56:37]Scanning done.Error sending telemetry
[00:56:37]Scanning...   
[00:56:37]Cannot report: mqtt disconnected
[00:56:37]Time remaining: 1052
[00:56:37]Cannot report: mqtt disconnected
[00:56:37]Time remaining: 699
[00:56:38]Connecting to MQTT
[00:56:38]Disconnected from MQTT.
[00:56:38]Starting MQTT reconnect timer
[00:56:38]restarted
[00:56:40]Connecting to MQTT
[00:56:40]Disconnected from MQTT.
[00:56:40]Starting MQTT reconnect timer
[00:56:40]restarted
[00:56:40]Cannot report: mqtt disconnected
[00:56:40]Time remaining: 1656

What now?

formatBCE commented 1 year ago

Ok, it's not an ESPHome. It's most probably mqtt, or TCP itself. Which makes sense.

Is MQTT reachable from other addresses? Try to check, what's wrong with it - looks like it doesn't allow connection...

It might be TCP connection trouble, or something with MQTT settings - unfortunately, can't tell precisely...

rospogrigio commented 1 year ago

Yeah I was searching and I believe that now you have to explicitely allow connections from other hosts. More checks tomorrow, now it's bedtime... thank you in the meantime :+1

rospogrigio commented 1 year ago

Yeah I was searching and I believe that now you have to explicitely allow connections from other hosts. More checks tomorrow, now it's bedtime... thank you in the meantime 👍

rospogrigio commented 1 year ago

OK solved: in debian bullseye, they have upgraded mosquitto to 2.0, which requires to set the option allow_anonymous to true, or to setup a password file for authentication: https://www.sigmdel.ca/michel/ha/rpi/mosquitto_rpios_bullseye_en.html

Old firmware is working again, will shift back to ESPHome tonight. Thank you for your support anyway!

Edit: flashed ESPHome, all working fine as earlier. Thank you again!

formatBCE commented 1 year ago

Great to hear you found the solution! My MQTT server does have authentication from scratch, so I won't have these problem, I guess :)

formatBCE commented 1 year ago

@rospogrigio hi!

I need your help here. As you know, i made changes to integration to skip checking response data from gateway (https://github.com/rospogrigio/airbnk_mqtt/pull/25). It works well, and i use it for several months without (almost) any issues. However, there's one thing that i can't fix: if i send command to unlock the lock, while it's already unlocked (it's possible with direct call) - then i can't operate lock anymore, till i open/close it by hands or via official app.

I remember, that there was something with incorrect payload (https://github.com/rospogrigio/airbnk_mqtt/issues/28) - but maybe, it's different bug?

Thank you in advance!

rospogrigio commented 1 year ago

I really don't know how to help since mine doesn't show this behavior. Have you tried to restore the response data? In any case, if the problem was the lockEvent not being updated right after the command, it should update when you receive the first ADV message so I'd be really surprised if it solved the issue. What you describe makes me think of a bug in the firmware of the lock and in that case there's nothing you can do, I'm afraid. Have you checked for any firmware update maybe? Just one question: what do you mean by "it's possible with direct call"? Sorry for not being more helpful...

formatBCE commented 1 year ago

Oh, i forgot to mention, that I created "lock" entity from that "cover" - and it prevents from trying to open lock, if it's opened already. But direct call to service "lock.unlock" still is possible. So automations sometimes cause that behavior (if, for example, me and my wife coming home together).

Also I forgot to mention, that with this bug, I see error logs in HA:

**Logger: custom_components.airbnk_mqtt.custom_device Source: custom_components/airbnk_mqtt/airbnk_logger.py:44 Integration: Airbnk lock (MQTT-based) (documentation, issues) First occurred: January 22, 2023 at 12:41:38 (42 occurrences) Last logged: January 23, 2023 at 17:30:17

Command sign: 1674523658 Received sign: 1674523798 Command sign: 1674523798 Received sign: 1674523816 Command sign: 1674523816**

It's almost like integration is "ahead" in expected sign... IDK what that means though...

rospogrigio commented 1 year ago

Mmm... well, that logging comes from custom_device.py, and it is wrongly logged as an error. See the code:

        self.logger.error("Received sign: %s" % msg_sign)
        self.logger.error("Command sign: %s" % self.cmd["sign"])
        if msg_sign != self.cmd["sign"]:
            self.logger.error("Returning.")
            return

The first message posted is Received and then Command, and since they are equal everything is actually working fine. We should change the level to debug instead of error, but this is actually not an error and moreover doesn't explain what you are experiencing. Does it happen also if you use the cover entity instead? I really don't see the advantage in using a lock instead of a cover...

formatBCE commented 1 year ago

You're right - looks like I need to put that to debug... :)

Behavior with cover is same, I'm afraid.

I created lock entity as template (it's just better looking in interface).

rospogrigio commented 1 year ago

OK. But when it happens, does restarting HA solve the issue? Because if it doesn't, then the problem is definitely in the lock's FW.

formatBCE commented 1 year ago

I tried to reload config entry for your integration, and it doesn't fix the issue...

However, vendor app still operating without any issues, which brings me to decision, that we miss something...

rospogrigio commented 1 year ago

Good point. I'd try a restart of HA and see if it solves because that's one of the key aspects. Then, I think we should compare two ADV messages, one when it's operating normally and one when it's in the stuck condition, and look for differences.

formatBCE commented 1 year ago

Ok will do it today!

formatBCE commented 1 year ago

Here's the list of payloads:

Failed state (doesn’t work):            baba0303010400363030303539380000014a00000d829a000000
Unlocked manually:          baba0303010400363030303539380000014a00000d838a000000
Locked manually:            baba0303010400363030303539380000014a00000d839a000000
Unlocked with HA:           baba0303010400363030303539380000014a00000d848a000000
Locked with HA:                 baba0303010400363030303539380000014a00000d859a000000
Sent another lock command:          baba0303010400363030303539380000014a00000d859a000000

Basically, lock doesn't change the payload, if command doesn't change its state. First command is getting response (lock beeps), and then it just doesn't respond to the commands.

Do you think there's something with that "commands count", that is increasing each time on new command?

P.S. forgot to mention: HA restart doesn't bring it to life. Only operating manually or via vendor app.

rospogrigio commented 1 year ago

So, the only relevant part is the dxxxa towards the end. We know that 0d82, 0d83, 0d84 etc is the command count. This values changes all the time so that if anybody would sniff one unlock command he cannot recycle it because this value has changed and so he would need to encrypt the new one. Then, we have 8 for open status and 9 for closed status, so far so good. When you write "Sent another lock command" do you mean using HA? Did it have any effect? In any case, nothing useful is coming out from here, yet the vendor app is able to operate the device when it's stuck. Other things I would try are:

formatBCE commented 1 year ago

do you mean using HA Yes, using service lock.lock.

Lock beeped. After that, no response from lock at all on consecutive commands.

Will try to check other characteristics - maybe something useful there.

Do we have decompiled WeHere app code somewhere? Lost that thread...

formatBCE commented 1 year ago

Ok, there's something from nRFConnect:

Remember that read characteristic 0xFFF3? When i break it intentionally, that value becomes really strange. Like, with a lot of 00 bytes.

Adv payload remains valid though.

I remember conversation about it, but don't know what to do with it. I'm sure, that fix is something there. for this, though, i will need to connect to characteristic and read that data. Can't imagine what to do with it after.

I guess i need to look into official app. Must be an answer somewhere there.

formatBCE commented 1 year ago

I remember, @nourmehdi had decompiled app. Probably, we can ask them? Or you have one too @rospogrigio ?

formatBCE commented 1 year ago

I decompiled APK, and trying to get through shitty code. It is so bad, that my eyes are bleeding (I'm Android/Java dev with 15 years of experience)...

There is something with fff3 characteristic, that might have impact. Will dig deeper. Don't know if it's worth it, but crap, why not. :)

formatBCE commented 1 year ago

I see function: ClientManager.getClient(this.mContext).notify(this.mMac, ServiceUUID, NotifyCharacteristicUUID, this.mNotifyRsp); It is called each time app sends command to the lock. mNotifyRsp is callback, receiving data change from that FFF3 characteristic. There's a lot going on, and i guess i'll need some time to create test firmware and debug/parse that.

For now, i see that payload received is checked with this rule: if (bArr[0] != -86) { return error; } if (bArr[5] != 0) { return error; }

So basically if first byte not equals to AA, and 6th - to 0, it indicates error.

P.S. Just checked: that characteristic status does have "06" in 6th byte, if command stuck. BUT! On first "incorrect" command (which hangs the lock, but beeps) FFF3 value doesn't contain error - only on second command, when lock already doesn't respond. However, it is changing. Will check, how exactly it is changing, and if vendor app can operate lock, if incorrect command was sent (with "06" code in FFF3).

P.P.S. Checked.

  1. Vendor app is able to recover lock from that bad state (over bluetooth that is, don't have stock gateway installed).
  2. FFF3 payload:
    1. Normal state: AA-00-11-02-04-00-F0-01-04-00-00-00-0D-93-01-4E-9A-00-00-84
    2. After first unreliable command from HA: AA-00-11-02-04-00-F0-01-04-00-00-00-0D-94-01-4E-9A-00-00-85
    3. After second unreliable command from HA: AA-00-04-00-00-06-06-00-00-00-00-00-00-00-00-00-00-00-00-00