@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.
@yveaux said in Ikea Molgan Hack:
@magpern the instructions on openhardware.io state that the Molgan must be battery powered while programming:
Well, then I can confirm that you don't have to power the Molgan from batteries just for programming. Burning the bootloader works fine with just power from the ISP port and programming it through FTDI works fine if power comes from the FTDI.
What I found wierd is that the atmega328 had power, the radio had power, it wrote debug messages to the FTDI - when powered through the FTDI, it send radio messages etc, but it just did not receive messages.
Messages where not received until I supplied power to the + / - pads (battery pads).
I did read the instructions on openhardware.io, but I didn't follow then to the t.
@michlb1982
A couple of things, you put the device to sleep so while it's asleep, it won't respond to the commands to change the relays. Since you are combining relays and sensors, you need to keep the unit awake and find a different way to send the sensor data occasionally. For the relay status, read the comments in the sketch. You are saving the relay state and then reading that on startup. You can eliminate all of that code and just set the relay to off in the setup section.
Cheers
Al
This should work with Domoticz, it's what I intend to use with it. I've received the boards from China and I'm currently working on a version 2 of this board. There are some errors in the design of version 1 that I need to get out. New version will be up shortly.
The choice of MOSFET can be tricky. Seems that irlz44n was discontinued so you may need to find one adapted to the voltage and current you want to handle.
In all the cases you need to get a logic MOSFET too, meaning that they are fully open usually around 1 to 3V.
Also I'm sort of confused as it seems to me that L7812CV is a Voltage regulator, not a MOSFET. So if you are actually using that in the MOSFET spot it will definitively not work.
Especially if you are handling high current or voltage I would recommend using one from a reputable source for your MOSFET, I recently switched from mouser / digikey / aliexpress to mostly use http://www.arrow.com as you get free regular shipping, event if you order a couple of components (no affiliation to them whatsoever).
