Flow, Rain, Soil Sensor Inputs, Current Sensor

[Csaba Toth]

I have set up the three inputs and current sensing hardware as I posted here:
https://opensprinkler.com/forums/topic/couple-of-questions-2/.

Based on 2.1.7 I have modified the firmware too.
The firmware working fine on the modified hardware, but there is some issue with the web and mobile interface.

Looks like the expanded options list in defines.h makes this issue:

start_of_code part>>>>>>>
/** Macro define of each option
* Refer to OpenSprinkler.cpp for details on each option
*/
typedef enum {
OPTION_FW_VERSION = 0,
OPTION_TIMEZONE,
OPTION_USE_NTP,
OPTION_USE_DHCP,
OPTION_STATIC_IP1,
OPTION_STATIC_IP2,
OPTION_STATIC_IP3,
OPTION_STATIC_IP4,
OPTION_GATEWAY_IP1,
OPTION_GATEWAY_IP2,
OPTION_GATEWAY_IP3,
OPTION_GATEWAY_IP4,
OPTION_HTTPPORT_0,
OPTION_HTTPPORT_1,
OPTION_HW_VERSION,
OPTION_EXT_BOARDS,
OPTION_SEQUENTIAL_RETIRED,
OPTION_STATION_DELAY_TIME,
OPTION_MASTER_STATION,
OPTION_MASTER_ON_ADJ,
OPTION_MASTER_OFF_ADJ,
OPTION_SENSOR_TYPE,
OPTION_RAINSENSOR_TYPE,
OPTION_WATER_PERCENTAGE,
OPTION_DEVICE_ENABLE,
OPTION_IGNORE_PASSWORD,
OPTION_DEVICE_ID,
OPTION_LCD_CONTRAST,
OPTION_LCD_BACKLIGHT,
OPTION_LCD_DIMMING,
OPTION_BOOST_TIME,
OPTION_USE_WEATHER,
OPTION_NTP_IP1,
OPTION_NTP_IP2,
OPTION_NTP_IP3,
OPTION_NTP_IP4,
OPTION_ENABLE_LOGGING,
OPTION_MASTER_STATION_2,
OPTION_MASTER_ON_ADJ_2,
OPTION_MASTER_OFF_ADJ_2,
OPTION_FW_MINOR,
OPTION_PULSE_RATE_0,
OPTION_PULSE_RATE_1,
OPTION_REMOTE_EXT_MODE,
OPTION_DNS_IP1,
OPTION_DNS_IP2,
OPTION_DNS_IP3,
OPTION_DNS_IP4,
OPTION_SPE_AUTO_REFRESH,
OPTION_IFTTT_ENABLE,
OPTION_FSENSOR_TYPE, //SG version flow sensor Option
OPTION_SSENSOR_TYPE, //SG version soil sensor Option
OPTION_DSOILSENSOR_TYPE, //Digital soil sensor type NC/NO
OPTION_SOILCAL_LOWY, // analog sensor calibration lowY value (%) default 0
OPTION_SOILCAL_LOWX_0, // analog sensor calibration lowX (mV) default 0
OPTION_SOILCAL_LOWX_1,
OPTION_SOILCAL_HIY, // analog sensor calibration highY value (%) default 100
OPTION_SOILCAL_HIX_0, // analog sensor calibration highX value (mV) default 2500
OPTION_SOILCAL_HIX_1,
OPTION_SOIL_ACTIVATE, // Analog soil activation level (%) default 50
OPTION_CSENSOR_TYPE, //SG version current sensor Option (option line 35)
OPTION_RESET,
NUM_OPTIONS // total number of options
} OS_OPTION_t;
end_of_code part >>>>>>>>>

Of course I have modified the option_prompts, max, default values, and the setup functions too.

The modified firmware is handling the inputs -still need a lot of refinement-, but the web and mobile app can’t start.
The webpage is starting, but infinitely restarting the first page (the “Loading” text appears on the page or the password window if applied the password).

What could be the explanation of this issue?

What I should change to use the web or mobile application?

Thanks, Csaba

[Csaba Toth]

Finally and happily I was able to launch my JTAG ICE debugger on OpenSprinkler:
– use the I2C LCD, it works automatic flawless, thanks Ray,
– a bit of reorganization of pin functions to release PC2 – PC5,
– Setup Atmel Studio 7 + Visual Micro + Atmel ICE.
Now Hw breakpoint feature is in operation and I see, I should change topics because the firmware works well.

The UI is start over continously calling the html header.
Probably there has been changed some data what makes an infinite loop in the UI.
I haven’t changed a lot in the existing code, but there are 3 sensors paralel what used to be on one input before.

I haven’t explored the UI, how can I get the UI back to normal operation?

[Csaba Toth]

I have found the solution.
The op_json_names list have to be synchronized with the option list.

Now I have flow, current logs on the SD card, the code part:

ultoa(curr_time, tmp_buffer+strlen(tmp_buffer), 10);
if((os.options[OPTION_SENSOR_TYPE]==SENSOR_TYPE_FLOW) && (type==LOGDATA_STATION)) {
// RAH implementation of flow sensor at the end of all progammed station cycle
strcat_P(tmp_buffer, PSTR(“,”));
#if defined(ARDUINO)
dtostrf(flow_last_gpm,5,2,tmp_buffer+strlen(tmp_buffer)); //the flow log
strcat_P(tmp_buffer, PSTR(“,”));
ultoa(os.read_current(), tmp_buffer+strlen(tmp_buffer), 10); //the current log
#else
sprintf(tmp_buffer+strlen(tmp_buffer), “%5.2f”, flow_last_gpm);
#endif
}
strcat_P(tmp_buffer, PSTR(“]\r\n”));

The log record looks like this:

[254,0,60,1485681437,121.70,296]

Program once, station1, 60 seconds, unix time, liter per minute, current milliamper.

[Ray]

OK, seems you were able to fix the issue yourself. Is there still any issue remaining? Yes the op_json_names list also needs to be completed if you define new options. In order to optimize the flash and RAM usage, the code is kind of hackish and I admit it can look confusing at places.

[Csaba Toth]

Thanks Ray,

My prompt answer has been lost somewhere.

I had have a period of other projects duty. But now I am back to finish the coding of the sensor handling.

In ver.217 the 17 program space is 2433 bytes what shows one program needs 143 bytes. Is there a program structure layout?
To handle the flow and current alerts we need minimum of 112 bytes plus some OPTION bytes as I see now.
The only option is to decrease the number of programs by one or two to make the space.

There is a 24aa.. I2C eeprom in the OS design. I haven’t found any code what using this memory.
What is the original purpose?

From ver.216 minor4(?) SD is a must. As I see this is needed for additional storage space. Do you have some plan for increase the internal memory space?

Csaba

[ShawnHarte]

The program structure can be found in the program.h and program.cpp files. You may need to edit portions of Opensprinkler.cpp, program.cpp, server.h, server.cpp, and main.cpp to add new features and set or modify them using the device buttons or json web interface. There is a lot to look at but the best way to go about adding a feature is to trace another existing feature through the program.
Also if you are adding to the size of any of the structures be sure to allocate enough space for it in the nvram. You can find a decent table of its format in the defines file. You will want to write down your current programs as once you change the layout of the memory you will not be able to import your old programs.

Good luck it can be really rewarding to add a feature and see it working in the real world. Make sure to fork the project on github and post your changes there as it can be useful to others to see what you have done. It also makes it easier for someone to help with an issue to see the full scope of your changes.

[Ray]

@tcsaba101:
“In ver.217 the 17 program space is 2433 bytes what shows one program needs 143 bytes. Is there a program structure layout?”
– As Shawn said, the program data structure is in program.h. Also, you can take a look at defines.h which shows the EEPROM layout — because most controller settings and programs are stored in EEPROM, it shows you where the program data exists. I believe the very first two bytes of the program data region are a program version identifier, and a program counter (i.e. how many valid programs there are). From the third byte, it stores each program in a ProgramStruct defined in program.h. In defines.h, MAX_PROGRAMDATA indicates the entire program data size. That minus 2, divided by PROGRAMSTRUCT_SIZE, gives the maximum number of programs allowed.

“To handle the flow and current alerts we need minimum of 112 bytes plus some OPTION bytes as I see now.
The only option is to decrease the number of programs by one or two to make the space.”
– Yes, you can reduce the number of programs to achieve this. The easiest way is to go to defines.h, reduce MAX_PROGRAMDATA. The rest of it (like MAX_NUMBER_PROGRAMS in program.h) is automatically calculated.

“There is a 24aa.. I2C eeprom in the OS design. I haven’t found any code what using this memory.
What is the original purpose?”
– This is a Microchip 24aa02e48 eeprom that comes with a hardware programed Mac address. Another use of this is to store the hardware type (i.e. AC vs. DC) so that the firmware can tell which version it is. The AC vs. DC signature is software programed (i.e. at the time of flashing the initial firmware, this signature is programed into the eeprom). Other than that, the rest of the eeprom space is available to store custom data.

“From ver.216 minor4(?) SD is a must. As I see this is needed for additional storage space. Do you have some plan for increase the internal memory space?”
– I think SD is a must from firmware 2.1.7 on OS hardware version 2.3. The reason is that some of the advanced features, such as IFTTT, remote and RF stations, etc. require storing data onto the SD card. Technically it’s not mandatory (for example, this is not enforced on OS hardware version 2.0 to 2.2, because they don’t support some of the advanced features). So if you don’t need them you don’t have to enforce SD card (and as I said, the firmware does not enforce it for OS 2.0 to 2.2)

[Csaba Toth]

Ray and Shawn

Thank you for the answers.
I have realized in meantime the options are calculated automatically if I rewrite the MAX_PROGRAMDATA parameter. Thanks for the clarification of the 2 starting bytes.
The eeprom MAC address is quite new for me. I think there should be a “default MAC” in the firmware, because it works without this eeprom populated, but I only tried with one instance.
May be you have analysed using flash memory instead of SD, because SD is not a long term memory solution in my mind.

WE have started a cloud based experiment to eliminate the dynamic IP, and port forwarding features.
My idea is to set up a data puffer between the UI requests and the firmware responses.
The firmware regularly polls the cloud server sending the answer to “Get All = /ja?..” content to the server. The server stores the results.
Each day logs also stored on the server.
If there is a request from the UI what can’t be handled based on the “polled data” the server would sending to the firmware as an UI request.
The firmware will make the answer and changes what is requested, like present style.
The server have to keep the UI in controlled waiting position till the time while the firmware will poll next time the server and can serve the request.
The server will know when the next poll is expected, so the UI can be informed the user how long have to wait for the action.

At the moment we have the server side what communicate through the API commands to the firmware and stores the answers.
Next we should make the polling function in the firmware.
Some new API function will be applied to handle the sensor’s data and the cloud operation.
Also the appropriate UI changes should be done, what still the weakest point.

I would like to see your opinion about the idea.

[Ray]

“The eeprom MAC address is quite new for me. I think there should be a “default MAC” in the firmware, because it works without this eeprom populated, but I only tried with one instance.”
– Yes, if the firmware does not detect the existence of 24AA02E48 chip, it will use a default MAC.

It’s not clear to me which particular idea you are asking my opinion on. I think you meant the general idea of a cloud based service and polling? That is a common way to implement cloud connection — it might be a bit slow due to the nature of polling (compared to some other options), but it should work as you described.

[Author]

Posts