I used the left one, it works.
The Meter Pro with CO2 is in the latest ESP32 code.
Aha, I copied the pictures from the hub version, but I copied the other temperature meter as the BLE driver template and forgot so I’m not sure what’s happened there. Unfortunately, the only way to see that is to publish the app.
I did update my ESP32 and indeed, Meter Pro is there!
Thank you so much.
And to add information about my test:
It works flawless both close to Homey Pro 2023 base and far away from Homey but in range of the ESP32-hub.
The RSSI-level from this Meter Pro CO2 is so much higher than from the Curtain units: -46 against -65 on the same distance from the ESP32-hub.
First project is a red flashing light when the CO2 value gets above 1000.
Aming for controlling the mechanical ventilation on this value…
Hello Adrian, thank you very much for the app! I have integrated an S10 vacuum robot. Status, battery and dock are working, all other functions get error messages:
Start und Stop
Error: Command is not supported by SwitchBot
Missing Capability Listener: vaccum_power_level.quite
Am I the only one who has a problem or is that known?
Warm regards
It’s the first I have heard of issues with it, but maybe there aren’t many users and I don’t have one to test with.
I will take a look at the code but could you set the log level to Full Information on the app settings screen and then create the errors and after that, go back to the app settings and tap on Send Log .
I have fixed the images in the new test version.
Did it, thank you so much for the quick answer!
Hello @Adrian_Rockall,
Thanks again for updating the ESP32 code! I managed to get my ESP32 board working with your latest code. Controlling the Curtain 3 motor (open/close) now works via the ESP32 BLE hub.
But it seems the ESP32 hub is somehow not correctly receiving or sharing the status info (like the curtain’s position) with Homey. As I understand from your initial post, this should be very quick and I should see the position slider, in the devices tile, move. This is not the case. It takes 10-30 secs before Homey updates the (final) position info. I assume it is Homey’s BLE antenna itself that receives the delayed data, not the BLE hub.
I also see the following error every minute in the log of the SwitchBot Homey app:
Invalid response code: 500: * 2024-12-04T21:03:31.926Z !!!!!!
Invalid response code: 500: * 2024-12-04T21:04:31.929Z !!!!!!
Invalid response code: 500: * 2024-12-04T21:05:31.943Z !!!!!!
Perhaps this is related?
I have already restated my Homey Pro, restated the SwitchBot app on Homey, repaired the Curtains 3 motor, and reflashed the ESP32 board to no avail.
Any ideas on how to solve this? Would it help if I share more detailed logs (and which level would you need)?
Could you set the log level to Full Information and allow it to collect data for a couple of minutes, then send the log.
Also, check the devices on the web page of the ESP32 and keep refreshing the page to see if that is updating the values.
I have sent you the log. Note that I did perform the following steps:
- Unplugged the ESP32
- Cleared the log in the SwitchBot Homey app
- Plugged in the ESP32
- Waited approx. 30 sec for everything to settle
- Issued the open curtains command (via the open/close button in the device’s tile). Waited for opening. Homey showed me a timeout message 10000 ms, though the curtains continued to open
- Waited approx. 45 sec for the position capability to update in homey
- Issued the close curtains command (via the open/close button in the device’s tile)
- Waited approx. 30 sec for the position capability to update in home
- Waited approx 1 min
- Issued the open curtains command again (via the open/close button in the device’s tile) and checked the ESP32’s web interface/device info. This info does not change and remains as follows, regardless of my continuously refreshing the page:
[
{
"hubMAC": "18... >> see log for full address",
"address": "C5...>> see log for full address",
"rssi": -43,
"serviceData": {
"model": "{",
"modelName": "WoCurtain3",
"calibration": true,
"battery": 71,
"position": 100,
"lightLevel": 1
}
}
]
- Waited several minutes
- Issued the close curtains command (via the open/close button in the device’s tile). and checked the ESP32’s web interface/device info. The output is the same as above: it never changes.
- Waited approx. 5 mins
- Issued the open curtains command again (via the open/close button in the device’s tile) and checked the ESP32’s web interface/device info. Again, the output is the same as above.
- Captured the log
I also noted that the device tile in homey reports an RSSI of -74, while the status code on the ESP32’s webpage indicated -43.
Hmm, it seems the new BLE library stops scanning when a connection to a device is made so a command can be sent. I am looking into solutions now.
New code and binary in GitHub.
Thanks! I tried the new code:
- The ESP32 board does seem to receive status updates now, based on the info in the web interface/device info json output.
- However, this info is not sent to Homey / Homey does not receive these updates. Only after 30-45 secs Homey receives the final update. I ussume via its own bluetooth antenna.
I sent you a new log with the result of powering on/connecting the ESP32 board + an open and close cycle of the curtain.
EDIT: @Adrian_Rockall I added some additional info:
The prior error message ‘ Invalid response code: 500’ is still reported in the log every minute. It seems this error is being triggered by the BLE hub trying to establish a connection with Homey but fails (I redacted the IP/MAC addresses):
2024-12-09T11:21:23.119Z * ------ Polling BLE Starting ------ * 2024-12-09T11:21:27.168Z * server got: SwitchBot BLE Hub! [MAC BLE Hub] from [IP BLE Hub]:1234 * 2024-12-09T11:21:27.175Z * Registering callback: http://[IP Homey]:80/api/app/com.switchbot/newData/ * 2024-12-09T11:21:27.179Z * callback/add * 2024-12-09T11:21:27.185Z * {"uri":"http://[IP Homey]:80/api/app/com.switchbot/newData/"} * 2024-12-09T11:21:27.188Z * { "host": "[IP BLE Hub]", "path": "/api/v1/callback/add", "method": "POST", "headers": { "contentType": "application/json; charset=utf-8", "Content-Length": 61, "connection": "Close" } } * 2024-12-09T11:21:27.208Z * Post response: { "message": "", "statusCode": 500 } * 2024-12-09T11:21:27.211Z * POST complete * 2024-12-09T11:21:27.216Z !!!!!! Invalid response code: 500: * 2024-12-09T11:21:28.168Z * BLE Finished Discovery * 2024-12-09T11:21:28.189Z * Polling BLE: waiting for devices to update * 2024-12-09T11:21:33.261Z * ------ Polling BLE Finished ------ * 2024-12-09T11:21:33.267Z * Next BLE polling interval = 30000
I hope this gives you some clues. Is there anything else I can try or any additional info I can provide you?
Hi Adrian, at the end of the day yesterday, i had a daily api limit warning message on my newly installed door sensor. Besides the fact that it generates many events during install,
Is that because i have 2 homeys on the same switchbot account polling the api for various sb sensors ?
If i understand correctly , you have a safeguard build into the app (stay below 10k api calls a day) so that safeguard only works per app/homey ?
Does the webhook (generated by switchbot cloud api upon an door sensor event) also count as an api call ?
Thanks in advance!
The safeguard is per Homey as they are not aware of each other, so that will be the cause of the message.
I will need to add a setting in the app settings page that allows you to tell each Homey how many other devices are connected to your account so they can share the quota.
The webhooks don’t count towards the quota, so there’s no problem there, but the webhooks don’t provide all the status information, hence the app still polls for that.
Perfect, so for now i organized all sb devices in 1 homey. I really like your app. From a fun perspective, will look at your esp hub solution
Hi @Adrian_Rockall I hope all is well. A question. I purchased the Pan/tilt 2k Plus camera’s. But they do not appear in the list when I try to add the cam’s to Homey. Is that correct. Are they nit supported?
Thanks Frans
I’m not sure, could you send the Device Log from the app settings page.
Even if it is supported, it will only be a motion detector as SwitchBot don’t allow access to the image.