Homebrew firmware hacking for latch mode without an expander

[akom]

Hello everyone and apologies if this is in the wrong category.

What I’m trying to do: I’m using a generic ESP8266 (Wemos D1 Mini) with an 8 SPDT optocoupled relay board to drive 4 latching sprinkler solenoids (DC). These of course need a ON and OFF pulse. My circuit (planned) is attached, it’s using 2 of the relays as an H-Bridge, 4 for the solenoids and 2 are unused. There is no boost. I don’t care about having an LCD, buttons, sensors, etc at this stage – just wifi control.

My question: What’s the most reasonable way to hack up the firmware to support this? I can see these possibilities:

1. Add a new hw_type (ie HW_TYPE_GPIO_LATCH). Add a bunch of conditionals in misc functions in OpenSprinkler.cpp to support this. Change auto-detection to default to my new type in the absence of expanders. The logic will be the same as the normal HW_TYPE_LATCH but without using an expander (direct digitalWrite)
2. Expand the “GPIO” station type (or add a new one alongside) that will support a configurable “Master” station that will act as an H-Bridge. In other words, add a “Latch GPIO” station type.

Any constructive thoughts would be welcome. I’m playing with the first option right now but haven’t gotten it to work yet. If I’m barking up the wrong tree, please tell me.

Attachments:

1. test2.pdf

[Ray]

Given that the firmware already supports Latch type of OpenSprinkler 3.0, you can simply modify apply_all_station_bits and also latch_apply_all_station_bits:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/OpenSprinkler.cpp#L994
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/OpenSprinkler.cpp#L971
You can certainly create a new hardware type as you said, and instead of auto-detect the type, you force the hardware type to be the new one you created. I don’t think you need to use GPIO station — changing those functions are more complicated than just modifying apply_all_station_bits and latch_apply_all_station_bits.

If it’s not a requirement to use unified OpenSprinkler firmware, you may also consider basing the work on the OpenSprinkler Bee firmware — it also uses ESP8266 and was designed to operate 3 zones. It’s easy to extend it to operate 4 zones as in your design.

Both OpenSprinkler and OSBee firmwares make use of I2C OLED. Your design does not seem to have an OLED display, and you use SDA/SCL lines as GPIO pins. So you will need to remove/comment out sections of code that handles I2C otherwise those parts of the code will end up interfering with your GPIO operations.

Also, be careful with using relays — I’ve previously had a version of OSBee using relays, it turns out the relays must support a relatively large amount of impulse current. I initially used a small relay rated at 2A contact current, that didn’t work. I had to change to a larger relay rated at 10A contact current, and that worked. Given that relays are very bulky, most latching circuits instead of transistor or MOSFET-based H-bridges, which are much more compact.

[akom]

Thanks Ray, that helps a lot (and explains why D1 and D2 relays don’t work with my modified code). (I had already modified the functions just as you suggested). I’ll play with it and digest your advice. I don’t really need to use the I2C pins in my setup. If I come up with anything worth sharing, I’ll follow up.

[akom]

For the record and if anyone goes down this path, I got it working (well enough for me).
It’s not pretty but should be easy to update when upstream changes occur.

My fork contains a brief explanation and the code: https://github.com/akomakom/OpenSprinkler-Firmware-CustomLatch

[Author]

Posts