I've added all the files manually so things should be there now (though I'd recommend grabbing things from github to preserve directory structure and get all the files).
@JahFyahh - I still haven't managed to et round to it. I've been really busy since this project and its still hectic here. I'm sure i read a few reviews somewhere, here or google. Not sure.
Hi!
I have the same problem as terxw. allpcb.com is missing the "NC drill date". Unfortunately I am not able to create this on my own. Can anybody upload this file?
Thanks
Hi @chey, no, with the pro minis and MySensors lib I couldn't get less.
Didn't measure with yet another multimeter though...
My battery sensors are working now for about a year and the battery levels are between 65% and 70%.
The sensor furthest from the gateway is at 65% and the 3 others at 70%.
Not bad I think.
https://forum.mysensors.org/topic/11499/checking-mechanical-locked-doors-by-a-battery-based-windows-door-sensor-node
Wow, great! Its alway nice to see others using my work too. Your code improvement seem to be very helpful too.
I have most recently also integrated this directly into my gateway build (see here). I am still struggling with code there though.
@Zwer2k my expectations seem correct. I created a bug report that also includes a rudimentary workaround.
https://github.com/mysensors/MySensors/issues/1496#issue-968399284
@NeverDie Thx for appreciating the work done. There will also be an open source part in the future. When and how extensive the open source part will be, remains to be seen. The release of certain information (block diagram, ..., in this post) is related to those open source parts.
There are some OBD solutions, however most of them (in my experience) give back low frequency data put by the car manufacturer on the OBD-bus (CAN, ...). Therefore transients evolving directly from the battery could only be recorded if the manufacturer sends those data accordingly on the bus. Due to the small bandwidth(also because of other car data that have to be sent, ...), such battery data are sent more often once per second or less. Fast battery events (i.e. cranking events, ...) are therefore imperceptible. Unless the manufacturer processes the fast events and then sends them (once per second or less), which is very unlikely if the manufacturer does not market this feature itself. Third parties devices for high frequency sensing costs several hundreds dollars.
In my experience, important battery states (especially the fast ones) are recorded by measuring and processing corresponding data directly on the battery.
I agree with you about the limits related to the communication over Bluetooth. But i think Bluetooth 5.0 will improve a lot. However, WiFi will always remain an important option due to the high data throughput. The combination of both (BLE & WiFi), especially with regard to energy consumption, will gain in importance.
