[cremeikas]

Awesome Ray,

I noticed that it seemed like it was possible to do this based on the code but wasn’t quite sure how to do it through the app. I think I’ll probably use this method for now!

[cremeikas]

To follow up on this again after a few days of going through the code, I think I mostly see what’s going on.

I’m doing this as a learning experience in using OOP and some new concepts, so I think I’m going to mostly rewrite a firmware version based on the unified version. I may restart a thread in a more appropriate section of the forum for anyone interested.

[cremeikas]

<quote> To adapt to pin64, the main modifications I believe would be to provide the pin definitions in defines.h and change gpio.h/.cpp to match gpio commands on pine64.</quote>

A quick follow up to this Ray,

Got my pine all setup to start trying to build and test on, and curious about some of the defines.

I think most of the functions in gpio.h/cpp are fine, calling the gpio pins through sysfs is pretty much the same from pi to pine. My question is about some of the defines:

I’m assuming these are the pin definitions

#define OS_HW_VERSION    OSPI_HW_VERSION_BASE
#define PIN_SR_LATCH      22    // shift register latch pin
#define PIN_SR_DATA       27    // shift register data pin
#define PIN_SR_DATA_ALT   21    // shift register data pin (alternative, for RPi 1 rev. 1 boards)
#define PIN_SR_CLOCK       4    // shift register clock pin
#define PIN_SR_OE         17    // shift register output enable pin
#define PIN_RAINSENSOR    14    // rain sensor
#define PIN_FLOWSENSOR    14    // flow sensor (currently shared with rain sensor, change if using a different pin)
#define PIN_RF_DATA       15    // RF transmitter pin
#define PIN_BUTTON_1      23    // button 1
#define PIN_BUTTON_2      24    // button 2
#define PIN_BUTTON_3      25    // button 3

#define PIN_FREE_LIST		{5,6,7,8,9,10,11,12,13,16,18,19,20,21,23,24,25,26}

But I’m a little unsure of some of the specifics. I’m using all of my own hardware for this, and from reading through the firmware code it seems as if there is some sort of controller that is used to control the valves indirectly.

I’m assuming SR_DATA and SR_LATCH are the primary pins that are providing the action for toggling on / off valves?

From the apply_all_station_bits function:

for(s=0;s<8;s++) {
   ...
   digitalWrite(PIN_SR_DATA, (sbits & ((byte)1<<(7-s))) ? HIGH : LOW );
   ...
}

In this context, does a station equate to a valve?

I feel like I’m missing some sort of relationship between the PIN_SR_DATA and each of the valves

Edit: So I think I understand a bit, it seems you are using some additional hardware to control the valves indirectly through some sort of relay that possibly takes an 8bit value to control the 1 available valves?

Thanks!

[cremeikas]

Not too sure about that, in it’s current form you’d have to manually add it to the code by hand and recompile. I can help if you run into some problems attempting it

My workflow so far has been almost a complete fork of the project as I’m kind of doing it as a learn experience.

[cremeikas]

I took Rays advice and extended the API to do this if you are interested Stril

/**
 * Enable or Disable a program
 * Command: /ep?pw=xxx&pid=x&en=x
 *
 * pw:    password
 * pid:   program index
 * en: 0 for disabled, 1 for enable
*/
byte server_enable_program(char *p) {
  byte i;

  ProgramStruct prog;

  // parse program index
  if (!findKeyVal(p, tmp_buffer, TMP_BUFFER_SIZE, PSTR("pid"), true)) {
    return HTML_DATA_MISSING;
  }
  int pid=atoi(tmp_buffer);
  if (!(pid>=-1 && pid< pd.nprograms)) return HTML_DATA_OUTOFBOUND;

  // Read the program
  pd.read(pid,&prog);

  // read the enable bit
  byte en=0;
  if (findKeyVal(p, tmp_buffer, TMP_BUFFER_SIZE, PSTR("en"), true)) {
    en=atoi(tmp_buffer);
  } else {
    return HTML_DATA_MISSING;
  }

  // Set enabled
  prog.enabled = en;

  // Write it back in
  if(!pd.modify(pid, &prog))
    return HTML_DATA_OUTOFBOUND;

  return HTML_SUCCESS;
}

I’ve only tested it in the demo mode, but in theory I think that is correct. Or at least a starting point if someone else has use for it.

Edit: Also don’t forget to add the ‘ep’ command to the urls / _url_keys structure at the bottom of server.cpp

[cremeikas]

Perfect, thanks guys

[cremeikas]

Thanks KSprinkler,

I ended up getting in, I think I was trying to access from the wrong port or something. I was able to get in through :80 after tracing through the code some to find the port.

I’m assuming the mobile app just ties into this through the API described in the link you posted?

[cremeikas]

Great

Thanks for the reply and the pointers on what to mod. Also, pretty nice to know about the simulation mode… I’ll get that a shot first to play around with the softwar

[Author]

Posts