Oh. the node.js version I am using seems to be correct with the app. When I tested yours and comparing it to mine, I was confuse as to why it is moving the opposite way. I thought maybe the sensors I created for the curtain was not correct. But, when examining your version a little more, I saw the position # is reverse.
I’ll look if there are different model numbers I can look for
You would need to have the physical model bot on hand to figure out the difference in code or can I examine it and find the values for you?
Hello all,
If anyone would like to test/try the new feature hold second on bots at bullet point #6, let us know if it works for you. A brief description about what it does is explained below the bullet points and how to setup here.
devWaves and I have tried it and it works for him, but not for me. He suspect that there maybe different bots. I have written the codes here for you to test this feature. You will need to change some settings to match your setup. Make sure you have V3.2 or higher installed on your ESP32.
Thanks.
Update:
It is now working for me. There was an error in the script which is now corrected.
HI, Not sure if this is something that i am doing wrong but i have around 8 pairs of switch bots and 2 stand along so 18 in total i would guess. a single bot and temp sensor. i have the latest firmware flashed well it was about a week ago but i’m having massive lag issues. some times it will react straight away but most of the time i have to wait anywhere from 10 - 120 seconds. i do only have 1 esp thou in the middle of the house and it does see all the devices. is there something i am doing wrong or i can look at etc. all the devices work and are seen in HA fine… just really confused as to what is going on.
are you sending commands to a bunch at the same time?
ok so the way BLE works is that you can only call one device at a time so if the esp32 is trying to send to one switchbot, then the esp32 waits for that to finish. also while the esp32 is scanning for device status updates, the esp32 waits before sending the commands. if there is one bot that is far away it can be delaying things for everything else
what is the worst connection link rssi you are seeing?
-40 rssi = really good
-90 rssi = really bad
you can watch for MQTT traffic on the main topic and the last thing should tell you what the esp32 is doing. you can also watch for the LED on the esp32 when it is lit up, that means the esp32 is doing something
LinkQuality rssi is part of the attributes. It is in the HA MQTT discovery fot each device. when looking at a device in HA you will see it listed
the issue is not necessarily that you have too many bots, just that if you have 17 bots all together real close to the esp32 and one real far away, that one will always make the esp32 take long during a scan
autoRescan using rescanTime variable will scan every 600 sec= 10 min
static int rescanTime = 600; // Automatically rescan for device info every X seconds (default 10 min)
so every 10.min it will scan for the latest status
/state of all your devices. you can set this to a higher number. rescanning is only a backup way to get the latest status/state. example: if you used the swichtbot app, a rescan will ensure HA has the proper state. a rescan by default can take max 2 min
I can’t say I have tested with that many bots
the code supports meters, but if you have a ton of devices it is a good idea to get at least 2 esp32, one for device ypu control (bot, curtain) and one for devices that always want the latest status (meters). if the esp32 is scanning for meter data all the time it can’t send control commands because the esp32 BLE is being used
you can call all 18 bots at once from HA, they will get processed one by one in the order they were received.
I’m doomed lol, ironically the worst connection is the monitor as well which is called more often. its defo lag as i was playing last night and some times i press the button and it’s instant then i try again a few mins later and it can take say 30 seconds or even you think it’s not working then randomly it works and your like oh it did work lol. so ideally take the monitor off and try again and then maybe split the bots over a couple of units i guess as well the more units you have the less time to process or wait if that makes sense.
ya, having at least one meter will make it scan often, and since the meter has a -92 rssi it is probably taking a long time to find it
definitely best to have a couple esp32s with the current design and a lot of bots
even switchbot recommends having multiple hubs, multiple esp32 is much cheaper
I am still making improvements to the design. I am looking at stopping a scan whenever a control command comes in to prioritize control over scan. When I figure that out it should resolve a lot of these long scan delays issues
if i get time tonight i’ll try taking the bot off and see what happens and then after that i will just add a couple of devices that are close and see what happens from that point of view. not an issues setting up some esp just much rather have local control over the units and not rely on the cloud etc as i was looking at the API for starters.
update lol, i took the meter off but left everything else on. i did a quick serial view before it had rebooted and it seemed to be scanning the meter every 10 -20 seconds and also taking a while to complete.
i took that off and now does its scans a lot less, didn’t time it but was obviously not scanning like it did.
i did move the unit closer to some of the curtains and the lag is now anywhere from 1 to 3 seconds normally and pretty consistent. obviously it takes longer it it happens to be at scanning time. the rssi is down to around 50 now for the ones i tried it on but it’s now in the same room. i think i’m going to knock together another unit and have that for the front of the house and one for the rear. the monitor can just be left as i don’t actually use it for anything at the moment tbf
sounds like you have a lot to do lol. well if you need any testers and i’m available let me know and i can try things out for you. As it happens everything seems to be running ok on one esp in the middle of the house. as i still haven;t had time to do another. in total i have the 18 curtain bots 3 normal bots but only using one at the min and a temp sensor if you need anything trying out like i said.
I was actually successful in figuring out how to have a control prioritize over scanning and I’ll try to release that later today
in the next update when it is scanning and a control/set command comes in it will stop scanning, process the command, then do a new scan after. This means you don’t have to wait if it is taking a long time to scan and in the middle of a scan.
youll be able to add your meter back again even with a -90 signal it shouldn’t affect control
action a hold+press using new MQTT topic example: switchbot/esp32/holdPress
When a set/control command is received while scanning, scanning will stop, process the command, then resume scanning
new property variables
static int defaultScanAfterControlSecs = 10; // Default How many seconds to wait for state/status update call after set/control command. *override with botScanTime list
static int defaultMeterScanSecs = 60; // Default Scan for meter temp sensors every X seconds. *override with botScanTime list
static bool printSerialOutputForDebugging = false; // Only set to true when you want to debug an issue from Arduino IDE. Lots of Serial output from scanning can crash the ESP32
