@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.
@Sunseeker According to the Connecting the Radio page, D2 is the default pin for the CE signal for the NRF24. If you'd like to use this pin for I2C, you can free it up by assigning a different pin for the CE signal by adding this line to your sketch:
#define MY_RF24_CE_PIN pin
IIRC, all available pins should work for this purpose (D0, D3, D4). Just pick one and if it doesn't work, use one of the other pins. Please make sure to add that line before #include <MySensors.h>.
@Andrew-Currie Downloaded KiCad and used it to import jBoard2.brd and output .gbr files via Plots plus the .drl file. Checked using GerbView and uploaded to PCBWay. Hopefully this will now work...
@GLAB No worries, was in a similar situation.. My perspective was on what the Node could be made to provide, not what could be done within Domoticz to address the requirement - eg Had heard of Dummy counters but had no experience nor understood their purpose, nor had ever used scripts.
I had been sending a logical ON/OFF as well as a cumulative total from the Node and hit the same hair-pulling scenario as yourself.
Now only the ON/OFF is sent and the short script makes the transposition within Domoticz to a dummy meter (I think kWhr) using the internal clock in Domoticz.
Have fun
