Well, here’s the deal: I initially used a PCB from an ESP8266 project, but it didn’t work out well - in fact, I almost fried the FILO motherboard with it.
That’s why I switched to using the stock BiDi WiFi module instead, since it already has an ESP32 built in. I found the right pinouts and flashed it with ESPHome. It’s been working really well to this day, although as I mentioned, it can no longer be updated with newer ESPHome versions, so the firmware isn’t up to date.
If you’re interested in the details, here is the ESP8266 project that didn’t work out for me: URL
And here is the guide for reflashing the BiDi WiFi module: URL and URL
Sorry, this sat unanswered far too long. You’d found a real bug, and it’s fixed now.
Your Spido reports its current position fine (5910 in your log), but when asked for the encoder’s maximum it answers 0xFFFF — which isn’t a real value, it’s the controller saying “I don’t have one”. The component took it literally and used it as the scale, so 5910 out of 65535 came out as 9%. The bug was in my code.
Two things changed: that “unknown” answer is now recognised as such wherever it appears, and for controllers that don’t report a programmed open position at all, the component learns it from the encoder the first time the gate reports fully open. If you’re still running this, updating should just fix it — and if it doesn’t, I’d genuinely like the startup log.
The component had a lot of work over the last few weeks, so a quick summary for anyone still following.
More controllers work now. The big one is the MC824H, which sits inside a lot of 24V dual-leaf kits — Toona, Hyke, Wingo HS, Titan HS, the Fab range, Hyppo. Those have two encoders and report positions in a different shape, which the component was misreading, so the gate would flip between open and closed while sitting still. Confirmed working now on a Toona and a Hyke.
Discovery got fixed for anyone with an OXI receiver on the bus. It used to pick the control unit by its address, which meant an OXI plugged in at the wrong spot got treated as the motor and nothing worked. It now asks what each device actually is.
Some new options: pinning the control unit address manually, ignoring the encoder entirely if your controller reports rubbish, and forcing a re-scan of the bus without a reboot.
There are proper tagged releases now, so instead of tracking whatever’s on main you can pin a major version and get compatible fixes automatically:
Almost all of the recent work came from people posting logs from controllers I don’t own — I have exactly one gate here, a ROBO600, so anything outside the Robus family is only fixable if someone shows me what their controller actually says on the wire. If you’ve got a Nice gate and a spare BiDi-WiFi, reports are very welcome, especially from anything that isn’t working.
I can confirm the component now reports the correct percentage for me.
I have just checked the forum after a long time, very satisfying to see these recent updates.