Connection error: Attempt 1 failed with BleakError: Characteristic 0000fff1-0000-1000-8000-00805f9b34fb not found! #22
Comments
|
I’m currently on business trip, so limited what I can do right here, right now. Maybe I’ll have some time tomorrow evening or during the weekend. Could I get you to take a look at this: #11 - specifically this comment: #11 (comment) Your board is identified as the old revision, but the characteristics seems to be unavailable, so I’ll need a dump of the characteristics that the box provides. |
|
Hi, python3 getServicesByAddress.py --address 9C:A5:25:BD:03:1D Hope it helps. |
|
I've committed a couple of changes. I'm a bit unsure if it'll fix the problem. It's the most slim service overview I've seen so far, but at least the different characteristics providing notify and write, have been added. Please look for "Device ({address}) identified as other revision" in the log -- debug isn't needed at this point. |
|
Hi, |
|
Shouldn't be a problem, as the evsemqtt-ha has this: I've updated with another check instead. Give it a shot. |
|
Hi, |
|
Okay - I've dumbed it down even further, to only check for the service UUID 0003cdd0-0000-1000-8000-00805f9b0131 - which seems to be unique for the board revision you're running. In a couple of minutes, the new build should be available. I'm not into the whole HA addon thing - but if there's a way for you to force, that the latest image is being pulled, that should be enabled. |
|
It is connecting now, but I get another error in the logs: |
|
Woah. That's something else. So a couple of obersvations:
The above will require, that additional debug facilities are implemented, so that non-documented (according to my research) commands, can be logged in full, in a separate file. What version of the EVSE Master app are you using on your phone? |
|
I'am using app version 2.1.25 |
|
In mqtt I get: |
|
Well, something is off. The amperage is weird -- 187A is quite extreme for a 32A rated device. I might need to decompile 2.1.25 -- I haven't been in there since 2.1.22, so they might have added something new. How old is the wallbox? |
|
The wallbox is from May 2021. It is a single phase |
|
Strange - then we should not get any readings for L2 and L3. I would be surprised if the scheduling had anything to say, as we shouldn't be parsing any of the charging strategies. Would you by any chance be running android on your phone? |
|
Yes, running on android |
|
Any chance you'd be willing to do a Bluetooth HCI packet dump? I'm not seeing any reference to either the UUID (0003cdd0) or the commands that appeared in the log you shared. The packet dump would help me in terms of figuring out, what goes on. |
|
No problem, how do I do that? |
|
You'll find a guide here: Retrieving the HCI Log It requires the developer options to be enabled. |
|
btsnoop_hci.log |
|
Perfect - thanks. I'll have a look through it -- might take a while, but I'll get back ASAP. |
|
So, a few observations.
I'm wondering if the parser is too lax, and thus allows for corrupted packages to come through. We might need a separate branch, in order to handle this, as it supposedly will be somewhat of a development/research effort. As a test - would it be possible to disable the schedule, just to remove that possibility? Lastly - when was the wallbox last rebooted? |
|
Hi, a new log, without the scheduling enabled |
|
I'll sift through the log later tonight. Have you tried connecting with the library after disabling the schedules? Just out of curiosity 😄 I'll admit to not having used EVSEMaster enough, to figure out how the whole scheduling part works - so haven't tested with it. |
|
Hi, Starting evseMQTT ... |
|
Can you try another Bluetooth Modul? Had similar problems with an old 4.2 dongle. |
Tested with 2 different bluetooth dongles (Realtek Bleutooth 5.3 & TP-link UB500)
|
|
Hmm. So it's working to some degree -- but still waiting for software version, which seems to be the last step, to enable full functionality. Maybe it would make sense to implement verification of the checksum, and discard any packages that are not correct. (well - d'uh!) |
|
Could you dump the debug log into a separate file? I think github might be eating some of the data. This line keeps repeating: evseMQTT - INFO - Received command 10 2025-02-03 19:54:59,407 - evseMQTT - DEBUG - Parsed data: {'header': b'\x06\x01', 'data_length': b'\x00\xb4', 'reserved': b'\x00', 'identifier': '8949281891483449', 'password': b'\xff\xff\xff\xff\xff\xff', 'cmd': 10, 'data': b"\x01Clock Fix Time Clock 1549220400\x00\x04\x02\x00\xb4'\x10\xc3P\x10\x01\x00\x00\x00\x00\W:0\Wd\x00\x00*", 'checksum': b'0\x00', 'end_byte': b'\x06A'} Command 10 is d_uploadLocalChargeRecord -- so, something's going on. Not sure if this would keep us from identifying the software version. Regardless the parser throws an error right after. |
|
Executive decision: we'll skip Command 9 and Command 10, as they're really not providing any value to Home Assistant, but rather is the product of my urge for "because I can" 😏 New commit coming up. |
|
f639560e_evsemqtt_2025-02-04T09-14-47.349Z.log |
|
Okay - so the parsing error is gone - wonderful. Might be a bit hacky, but we can always look into what goes wrong, if the historic charging records ever becomes relevant. How far away from the bluetooth adapter is the wallbox? Seems like connectivity is somewhat lacking -- RSSI is not written to the log, but should be in Home Assistant. According to the log, the login sequence more or less completes, however command 33030 (get_config_version) is never replied to with command 262 (set_config_version). According to the packet dump command 262 is actually replied - however, it's more or less empty and only providing gibberish. There seems to be a scenario, where command 262 will be empty and the hardware version becomes the software version. The screenshot from your app, indicates that hardware_version (replied in the login sequence) is the same as the "Firmware version" on the screenshot. Might require a fallback if 262 is not received or if it's empty, as it'll halter the final initialization of the library. |
|
Hi, |
|
I just got the follow (new) error: 2025-02-04 16:11:24,614 - evseMQTT - INFO - Retrieving RSSI for device 9C:A5:25:BD:03:1D |
|
The last error is the result of the non-graceful shutdown of the library, as mentioned in #20 -- I'm still trying to address that part. However - it seems the container might need a restart, to handle: Right now - as I see it, the focus needs to be on falling back to hardware_version if 262 is never received. I'll need to ponder that a bit, as taking hardware_version by default might prove troublesome on other revisions of the wallbox. |
|
If possible - I would like a log from the library starts in the container. |
I only have the library running as stand alone or as HA addon |
|
Standalone is alright -- that should allow for piping the output to a textfile rather easily. Something like We need to capture from beginning, to whenever it starts repeating Waiting for software version. |
|
f639560e_evsemqtt_2025-02-04T16-27-08.212Z.log |
|
That's usable. Thanks. There's a metric ¤#(" ton of malformed messages in there. A couple of questions, as I'm struggling to figure out what's going on:
As mentioned - there's a serious amount of malformed messages -- for instance:
header is correct. So at least, we got the beginning and the ending right 😅 My best guess at the moment, is that either:
|
|
Hi,
|
|
New logfile, after reboot wallbox, HA hardware, bt dongle now connect to HA hardware (without usb hub) |
|
Okay - great. Still a lot of malformed messages in there. So - a couple of follow up questions:
So far we have had the best results with the Realtek Bluetooth 5.2 dongles. I'll be looking into extending the library, so we can follow the sequence of the messages written to the device, and hopefully track which ones gets answered, and which doesn't. |
|
|
Perfect -- and no zigbee coordinators right next to the dongle? I realize, that I was mistaken - it's the Realtek Bluetooth 5.4 we've had good experience with. This one specifically: https://www.amazon.de/gp/product/B0DDPT1KM7/ Any chance you would have a RPI lying around? Just for the fun of it. I'm however not at a point yet, where I'm willing to attribute the issues to the dongle, as there's also strange messages in the phone packet dump. So please bear with me. |
|
No zigbee coordinators next to the BT dongle :-) |
|
Log from RPi , almost next to de wallbox. |
Hi,
I'am getting an error when connecting to my Besen BS20
2025-01-29 10:37:17,298 - asyncio - DEBUG - Using selector: EpollSelector
2025-01-29 10:37:17,303 - asyncio - DEBUG - Using selector: EpollSelector
2025-01-29 10:37:17,304 - evseMQTT - INFO - Scanning for evse BLE devices...
2025-01-29 10:37:17,713 - evseMQTT - INFO - Connected to MQTT broker
2025-01-29 10:37:22,420 - evseMQTT - INFO - Found device: ACP#Utopia (9C:A5:25:BD:03:1D)
2025-01-29 10:37:22,420 - evseMQTT - INFO - Connecting...
2025-01-29 10:37:22,420 - evseMQTT - INFO - Connecting to 9C:A5:25:BD:03:1D, attempt 1
2025-01-29 10:37:36,026 - evseMQTT - INFO - Device (9C:A5:25:BD:03:1D) identified as old revision
2025-01-29 10:37:36,026 - evseMQTT - INFO - Connected to 9C:A5:25:BD:03:1D
2025-01-29 10:37:36,027 - evseMQTT - INFO - Starting notifications for 0000fff1-0000-1000-8000-00805f9b34fb on 9C:A5:25:BD:03:1D
2025-01-29 10:37:36,027 - evseMQTT - ERROR - Attempt 1 failed with BleakError: Characteristic 0000fff1-0000-1000-8000-00805f9b34fb not found!
2025-01-29 10:37:38,028 - evseMQTT - INFO - Connecting to 9C:A5:25:BD:03:1D, attempt 2
2025-01-29 10:38:12,402 - evseMQTT - INFO - Device (9C:A5:25:BD:03:1D) identified as old revision
2025-01-29 10:38:12,403 - evseMQTT - INFO - Connected to 9C:A5:25:BD:03:1D
2025-01-29 10:38:12,403 - evseMQTT - INFO - Starting notifications for 0000fff1-0000-1000-8000-00805f9b34fb on 9C:A5:25:BD:03:1D
2025-01-29 10:38:12,403 - evseMQTT - ERROR - Attempt 2 failed with BleakError: Characteristic 0000fff1-0000-1000-8000-00805f9b34fb not found!
2025-01-29 10:38:14,404 - evseMQTT - INFO - Connecting to 9C:A5:25:BD:03:1D, attempt 3
2025-01-29 10:39:08,585 - evseMQTT - INFO - Device (9C:A5:25:BD:03:1D) identified as old revision
2025-01-29 10:39:08,585 - evseMQTT - INFO - Connected to 9C:A5:25:BD:03:1D
2025-01-29 10:39:08,585 - evseMQTT - INFO - Starting notifications for 0000fff1-0000-1000-8000-00805f9b34fb on 9C:A5:25:BD:03:1D
2025-01-29 10:39:08,586 - evseMQTT - ERROR - Attempt 3 failed with BleakError: Characteristic 0000fff1-0000-1000-8000-00805f9b34fb not found!
2025-01-29 10:39:10,588 - evseMQTT - INFO - Connecting to 9C:A5:25:BD:03:1D, attempt 4
2025-01-29 10:39:17,656 - evseMQTT - INFO - Device (9C:A5:25:BD:03:1D) identified as old revision
2025-01-29 10:39:17,656 - evseMQTT - INFO - Connected to 9C:A5:25:BD:03:1D
2025-01-29 10:39:17,657 - evseMQTT - INFO - Starting notifications for 0000fff1-0000-1000-8000-00805f9b34fb on 9C:A5:25:BD:03:1D
2025-01-29 10:39:17,657 - evseMQTT - ERROR - Attempt 4 failed with BleakError: Characteristic 0000fff1-0000-1000-8000-00805f9b34fb not found!
2025-01-29 10:39:19,658 - evseMQTT - INFO - Connecting to 9C:A5:25:BD:03:1D, attempt 5
2025-01-29 10:39:28,659 - evseMQTT - INFO - Device (9C:A5:25:BD:03:1D) identified as old revision
2025-01-29 10:39:28,659 - evseMQTT - INFO - Connected to 9C:A5:25:BD:03:1D
2025-01-29 10:39:28,659 - evseMQTT - INFO - Starting notifications for 0000fff1-0000-1000-8000-00805f9b34fb on 9C:A5:25:BD:03:1D
2025-01-29 10:39:28,659 - evseMQTT - ERROR - Attempt 5 failed with BleakError: Characteristic 0000fff1-0000-1000-8000-00805f9b34fb not found!
2025-01-29 10:39:30,660 - evseMQTT - ERROR - Error encountered:
Failed to connect to 9C:A5:25:BD:03:1D after 5 attempts
2025-01-29 10:39:30,661 - evseMQTT - INFO - Message published: 1
2025-01-29 10:39:30,662 - evseMQTT - INFO - Disconnected from MQTT broker
2025-01-29 10:39:30,667 - evseMQTT - INFO - All tasks cancelled, exiting...
My BESEN BS20:
Any ideas?
Thanks already
The text was updated successfully, but these errors were encountered: