ESP8266 Use native GPIOs

[Chassy33]

I have read through pretty much every post on here regarding using an ESP8266 and GPIOs. I see that most of the pins are used for buttons and such which is why a PCF8574 or PCA9555 are used with I2C, but if I was just running an ESP with no buttons or LCD would I be able to modify the code to use the built in GPIOs? I have tried to comment out all the I2C and LCD portions, as well as any unneeded pin assignments, and added all the available GPIOs to the PIN_FREE_LIST in defines.h but I cannot get it to ever show any available GPIO under the advanced station settings after compiling and flashing. Is this possible? Or is it way more complex than that? I tried to use some PCF8574s but couldn’t get them to trigger the relay. I know they can trigger it because I have wrote my own test code to trigger them using wire library. I have several PCA9555 GPIO expansion chips on the way, but they got lost in the mail so still waiting for them. I am a complete beginner with C++ but am still learning my way around. I wod love to be able to get it to work using just the native GPIOs if at all possible.

[Ray]

Hi, what you did sounds correct for the firmware part. But you will also need to modify the UI if you want those pins to show up in the UI. In the UI code, the free pins are hard-coded, and not transferred from the firmware to the UI, hence you have to modify the UI code:
https://github.com/OpenSprinkler/OpenSprinkler-App/blob/master/www/js/main.js#L5038

You can download the UI code, unzip it, and run it locally in a browser.

[Chassy33]

Ray,

Thanks for the super quick reply! I figured I was missing something. My question is this. If I edit the main.js to add another getHWVersion check for 3.2 (that seems to be what is the default when I flash to the ESP with no GPIO expander attached), how do I get that modified JS file to be included when I compile? Or is that JS file just called as a <script> tag in a HTML file? If that is the case then I would need to edit that HTML file as well, but once again, not sure how to get that included in the compile using the included make.lin32 file. Also I may be completely wrong on how I believe all of this works…

Thank you for all you work and help on this!

[Ray]

The UI (javascript) is not part of firmware. The way this works is that these javascript files are stored on opensprinkler server, when you type in the IP address of the controller in the browser, the firmware returns code to the browser to reference the javascript code on opensprinkler server. And if you use the mobile app, these javascript files are embedded in the app.

Since you are going to customize the UI, what you should do is to download the UI code, unzip, and run the index.html in a browser. If you type in the IP of opensprinkler in a browser, or use the mobile app, those javascript codes are not your customized code so it won’t work.

[Chassy33]

Duh that makes complete sense… Not sure what I was thinking. Thanks for the explanation. One other question. I am trying to get it to work using several PCF8574s.

I have the first I2C address set to 0x20 to tell the firmware that the version is 3.0. From my understanding, I cannot use any of the GPIOs on this chip for zones. Also without using this, If I hook up any other board, the ESP will not boot. So I have a second board with address 0x21 which is for AC driver and I can get it to trigger the first 8 zones, and the UI shows 8 zones available. Then if I hook up a board with address 0x24 which looks to be to address for the first expander board, the UI now says there are 24 stations available, but the GPIO on the 0x24 board drive zones 17-24. this continues on. each expander board with address 0x24-0/27 adds 16 more zones, but can only control 8 zones. I cannot get control of zones 9-16 no matter what I try. Is this normal?

[Ray]

I2C address at 0x24 is assumed to be the first expander, and by default all expanders have 16 zones. The OpenSprinkler expander first version used PCF8575 which is a 16-channel GPIO expander; the current version uses PCA9555, also 16-channels. Because these chips along with PCF8574, all have the same base I2C address, there is no easy way to tell them apart from the firmware’s point of view (although PCA8575 and PCA9555 can be distinguished from each other because PCA9555 has certain registers that PCA8575 doesn’t have). This is the reason why if you hook up another PCF8574 at I2C address 0x24, the firmware assumes it’s a PCA8575 instead, so assumes it’s 16 zones. Because of this, it will always send 2 bytes to that chip (16 bits) instead of 1 byte. If PCF8574 receives 2 bytes, I think the second byte overwrite the first byte, that explains why your 0x24 board drives zones 17-24.

There is another forum thread that also discusses PCF8575:
https://opensprinkler.com/forums/topic/driving-14-valves-or-12-main-pump-from-os-3-0/#post-71927

I would recommend you to consider using a PCF8575 board if possible (or PCA9555). If not, you will need to modify the firmware code so that it only sends 1 byte to the expander instead of 2.

[Chassy33]

I was under the impression that the first version used PCF8574 for main board and a separate PCF8574 for the expansion board. I had not seen that you used the PCF8575 expansion boards. So you are saying that if I have a board set as 0x24 it assumes its a PCF8575 rather than a PCF8574 and so it thinks that there are 16 stations per board? If that is the case, where would I modify the code to only send 1 byte rather than 2? I am assuming it is somewhere close to here?

https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/2b293a1c8712a05a95799bb3efa290ff771f4f46/OpenSprinkler.cpp#L1094

I do have some PCA9555 on the way, but don’t know when they will get here. Plus at this point, its almost a challenge to get this working.

[Ray]

The expander has never used PCF8574 because it only has 8 channels and expanders have always had 16 channels. The first version of OpenSprinkler used two PCF8574s on the main controller, one on the top board and one on the bottom/driver board. The bottom/driver board is not expander.

The code that handles expander is here:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/2b293a1c8712a05a95799bb3efa290ff771f4f46/OpenSprinkler.cpp#L1131
because it uses dynamic typing (i.e. expander[i] itself carries the type of the I2C chip), you will have to modify code in gpio.cpp:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/gpio.cpp#L118
the simplest hack is to remove the second Wire.write:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/gpio.cpp#L123
see if it works for your PCF8574.

[Chassy33]

Ray,

Thanks for that description. It makes total sense now. I was confusing the driver board with expander boards. I was able to get it all working using 2 PCF8574 boards, but today my PCA9555 chips showed up! So I soldered a new board and have it all working as 0x21 and it triggers my relays. the issue is that all the PINs are low and my relays are active LOW. is there somewhere in the FW to modify to keep all the outputs HIGH? Looking through the PCA9555 datasheet it looks like it is default HIGH INPUT on boot. so I am assuming that the FW pulls them all LOW and OUTPUT, but I cannot find where that is. From looking I would assume its within the apply_all_station_bits() but I am not sure of that.

https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/3c388712494393498b9fbdb2fa2725dc189f0a32/OpenSprinkler.cpp#L1094

Thanks again for all you help with this! I am learning a lot!

[Chassy33]

Ray,

I got it to work! I set the address to 0x21 (A0=0, A1=0, A2=1) which would be the AC Driver board, but if I only connect that single board to the ESP-8266, it sees it as the expansion board and utilizes its GPIOs for zones 9-24. this is perfectly fine with me as I just need to drive 8 zones and 1 master. But it just seemed like I would have to set the address to 0x24 for it to think it was an expansion. Regardless It is now working.

I was able to modify the firmware and reverse the OUTPUT state to make them all HIGH on the expansion board. Below is what I changed for anyone else that faces this issue:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/3c388712494393498b9fbdb2fa2725dc189f0a32/OpenSprinkler.cpp#L1129

for(int i=0;i<MAX_EXT_BOARDS/2;i++) {
uint16_t data = station_bits[i*2+2];
data = (data<<8) + station_bits[i*2+1];
if(expanders[i]->type==IOEXP_TYPE_9555) {
expanders[i]->i2c_write(NXP_OUTPUT_REG, data);
} else {
expanders[i]->i2c_write(NXP_OUTPUT_REG, ~data);
}
}

I edited the line “expanders[i]->i2c_write(NXP_OUTPUT_REG, data);” and reversed the “data” so it is now “expanders[i]->i2c_write(NXP_OUTPUT_REG, ~data);”

Thanks for you help!

[Ray]

That’s great to hear!

[Dan Christensen]

Just for others who find this discussion via search: The javascript UI now queries the controller’s firmware to find out the free GPIO pin list, so if the firmware is modified to add one or more pins to that list, the UI will correctly make them available.

[Chassy33]

Dan,

Not gonna lie, I was reading through all my past exchange with Ray and have no idea what I did to make it work. I lost my compiled code when my external drive failed and was trying to replicate this a few weeks ago for another setup but gave up.

So are you saying that all I need to do is update the “PIN_FREE_LIST” with free GPIOs and then compile and then the UI will see them as available? I just want to confirm that I understand what you are saying.

[Dan Christensen]

@Chassy33 Yes, that is correct. It was confirmed to me in a support ticket, and I also checked the code. In the javascript code, you can see that it queries the controller for its settings in this function:

https://github.com/OpenSprinkler/OpenSprinkler-App/blob/5818d27143e045dfc315348c752bfccb213a732f/www/js/main.js#L1146

And the controller replies here, putting the value of PIN_FREE_LIST in the response:

https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/e9e04b006f82a29f2bd2317770a170402fe1bca6/opensprinkler_server.cpp#L1192

You can also find the spot where the UI code looks up the gpio list in the response.

I will be testing this myself when my controller arrives, as I’m adding a ninth zone with an external relay.

[Chassy33]

Dan Christensen, I can confirm that this works. I compiled a default build with making no changes and could not set the station types to GPIO as there were no free pins listed in the PIN_FREE_LIST in defines.h. Then I modified the PIN_FREE_LIST to includes several pins and recompiled the code and now I can set the station type to GPIO and pick which PIN to use. I still need to actually connect some relays to the board, but it looks like this will work great!

[Dan Christensen]

@Chassy33 I also tested this today, and it’s working for me as well.

[Author]

Posts