This is happening to me as well now… i had 2 curtains now ive added 4. maybe is that? how edvices do you have per ESP device?
@natdeamer There is an issue caused by NimBLE library 1.3.8 that I haven’t had a chance to figure out. Ensure you are using version 1.3.7 of the NimBLE library
When testing, if the names you used aren’t working please try with the default names and reproduce the issue
I have 2 curtains, 3 bots, 4 contact sensors, 4 motion sensors setup. So number of devices shouldnt be an issue
2 Likes
ill give a a go tmorrow! thank you so much!
Thanks. Can confirm all is good now!
I may have spoken too soon. It seems to have locked up again.
To confirm, i changed this line in the platformio.ini file
From: h2zero/NimBLE-Arduino@^1.3.7
To: h2zero/[email protected]
@natdeamer I believe that should do it. Might need to manually remove 1.3.8 from the project. I have found that platformIO does some weird stuff sometimes. You can try the arduino IDE if u want
I’ve been running mine for many months, so we’ll get it going for u
@natdeamer what firmware version is ur curtain? mine are v3.9 and there is a v4.4 out
it sounds like the latest firmware has extra more dat in the advertised data which could be messing things up
all operational! Ty Skeletor!
1 Like
I started again from scratch and they now seem to be behaving themselves and hasn’t locked up yet. Although I do find the stop button to be a little slow but that could be signal related - I have a QUINLED-ESP32-AE on its way.
I’m on V3.9 so will hold off on upgrading.
Thanks for your help
1 Like
I am pretty amazed at this. I have 5 curtain switch bots and when I request to open all of them, it does successfully one by one in a space of 0.5 secs .
Amazing work !
1 Like
I do have a question, is there a way for Google home to recognize these curtains via HÁ?
Yes google home should work with the HA cover entity according to this…
1 Like
If anyone is using an “ESP32S” model by AI-Thinker with this project and has no issues (or has issues) can you please let me know?
I am just updating the docs so that people know which ones to buy and someone has mentioned they are having issues with this model. The specs look the same as the WROOM-32 so it “should” work from what I can tell
@devWaves I’m having an issue with the contact sensor - it seems to flood my logs many times a min all day. I only noticed it after trying to debug an unrelated automation. It’s on the ESP32 wemos mini d1 using latest from github. The screenshot was taken door closed. Any suggestions? The contact sensor is the only one attached to this ESP32.
@neveroffline is that specifically an issue? it is just logs. That value is the lastcontact value which is always changing, that is constantly being sent from the switchbot contact sensor. This is a separate value from the actual contact value broadcasted by the switchbot
the esp32 code will update contact topics when there is a change in values to motion/contact/illuminance but it will also force updates to the contact topics using the defaultContactScanSecs variable which is defaulted to 60 secs. You can increase that value and that will reduce the amount of MQTT topic updates and should reduce the number of logs but still maintain functionality
Others options are to not use the HA auto discovery devices and create your own sensor by manually looking at the MQTT topics you care about
if you do want to use HA auto discovered devices, but you dont care about the lastcontact value, just delete it from the esp32 code in this method publishHomeAssistantDiscoveryContactConfig
@devWaves Thanks for having a look. Specifically I guess I’m looking at changed to: SAME, SAME, SAME timestamp over and over. This doesn’t appear to be the desired behavior, but since it’s amounting to thousands of logs per day I figured I’d mention it. I will go back to the code and see if anything stands out. I’m ok with using the auto discovery etc and don’t want to change that.
@neveroffline so the reason why the value doesn’t look like it is changing is because of how the HA lastcontact entity data is created in HA
in the auto discovery MQTT message for lastcontact it subtracts the value sent from the switchbot from the current time "\"value_template\":\"{{ now() - timedelta( seconds = value_json.lastc ) }}\"
the value displayed in HA will say the same timestamp because now() always increases in seconds at the same time the lastcontact value increase, so one minus the other always give the timestamp of last contact.
if you want to see the actual value sent from the switchbot, which is an integer value, not a timestamp you can change it to send just value_json.lastc like so "\"value_template\":\"{{ value_json.lastc }}\"
@devwaves Do you have any plan to add the Switchbot Plug Mini (SwitchBot Plug Mini – SwitchBot US) to the supported devices?
@devWaves I went ahead and simply disabled the lastContact sensor on the switchbot contact sensor from within HA. No more excessive logging, and my automations still work. Just FYI. My suggestion is to not publish lastContact unless a change has happened on the sensor itself (breaking contact magnet) or maybe after a reboot/1st contact with the client. Thanks again for this great tool! Really awesome.
Here’s an example of how it looks now:
