Forum Replies Created

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • in reply to: vscode remote debugging configuration #79745

    ronnie
    Participant

    Update 3: SUCCESS

    Finally it all works. I am able to compile and remotely debug Raspberry pi 4 Opensprinkler code using vscode on my Lubuntu linux virtual machine.

    The final step was creating the launch.json file and learning how to use the vscode tools. I have attached the json files for anyone interested. Here’s a screen shot of a breakpoint on etherport.cpp:

    in reply to: vscode remote debugging configuration #79727

    ronnie
    Participant

    In answer to Dan’s question I want to develop code using the development tools VScode provides like breakpoints and tracking variables.

    So finally I have been able to compile opensprinkler using vscode. I reverted back to the previous release before 2.2.1 since that’s what I am running now. The first problem Dan pointed out was that I was trying to compile the entire gihub folder of files. So I created a project folder with only the files needed by the pi version. This left me with only errors related to the pthread mosquitto libraries. The vscode can’t execute “sudo G++” so I had to copy the 2 libraries to the project folder and change their ownership and privileges to non-root. I’m now working on getting GDB to perform debugging. The attached vscode task json file image contents result in duplicating the build.sh script G++ command.

    Attachments:
    in reply to: vscode remote debugging configuration #79714

    ronnie
    Participant

    Update 2:
    Now using the ARDUINO instructions for vscode. Installed the platformio extension and removed from the platformio.ini everything except the linux directives. This fixed many errors. However, using the platformio build I got a can’t find “WProgram.h” error among others. This error appears to be caused by emailsender.h

    40 #if ARDUINO >= 100
    41 #include “Arduino.h”
    42 #else
    43 #include “WProgram.h”
    44 #endif

    After commenting out this code the error is resolved. The “else” is executed even if not ARDUINO… Should there be another “if” in this ?

    The main remaining problem is openthingsframework is missing from the linux directives in the platformio.ini. Since openthingsframework is for ARDUINO I don’t think it is necessary for linux. But it has an include in opensprinkler.h.
    Anybody have any ideas?

    in reply to: vscode remote debugging configuration #79706

    ronnie
    Participant

    update:
    Adding a single line to the json file shown in the attached image solved the undefined references problem. However, the opensprinkler.h file has “includes” for files not in the source folder as shown in a second attached image. The third attached file shows some of the errors. The local G++ compile doesn’t seem to care but vscode sure does. Note openthingsframework seems to handled in the platformio.ini file build instructions for non-pi versions of the code.

    in reply to: Alternative to IFTT Pro #78533

    ronnie
    Participant

    For OSPI I use sendEmail.

    I send each IFTT notification to a text file. Then execute a cron script that periodically emails (all) the text file(s) contents. The script I use can accumulate several IFTT messages into a single email message.

    email setup for opensprinkler
    —————————-
    Install sendemail app
    install libio-socket-ssl-perl and libnet-ssleay-perl

    send email script instruction:
    sendEmail -f “fromaddress” -t “toaddress” -u “Subjectlinei” -m “Mymessage” -s “mysmtpserver”:26 -o tls=no -xu “loginusername” -xp “loginpassword”
    instead of -m use -o message-file=/tmp/file.txt


    ronnie
    Participant

    Ok, my guess was right. I ran a program three times using a 2hz flow signal with no wifi UI connection. The total water consumed reported in the log was 1802, 1802 and 1801. So the wifi ui is definitely hosing up the flow time measurement capability of the opensprinkler program.

    BTW I’m running buster Lite.
    The wifi connected UI offered a hint as to the problem by closely watching the flow count updates being reported. Every so often the number would jump through two updates in a row in less than a second.


    ronnie
    Participant

    I’m running buster. The pulse generator is a FY Economic 5 multi-function signal generator. I have header pin 8 monitored on a scope with a signal frequency readout capability. I ran another test at 6hz. I have attached a scope screen shot. The scope reports a frequency range of 5.99978 to 5.99980 with changes every few seconds. The UI while running a one time program of 15 minutes reports a flow rate range of 264 to 310 changing every couple of report cycles. After running the one time program twice the log reports total water usage of 4268 and 3970 for the two sessions.

    During running the one time program I’m viewing the UI which of course means the raspberry pi is continuously communicating via a local LAN wifi network with my pc. So it could be the Opensprinkler program time measurements could be affected.

    I’ll try running a watering program twice with no UI connection.

    Attachments:
    in reply to: Hall sensors in parallel, and/or perhaps too high pulse rate? #78157

    ronnie
    Participant

    I’m testing the flow rate measurement capability of OSPI 2.2.0 on a raspberry pi zero 2w. I’ve attached a pulse generator to pin 8 (GPIO14) and set the pulse rate to 1. Per your comment stating, 10 clicks per second max pulse rate, I set the rate to 4hz 50% duty cycle ( 4 pulses per second). I manually ran a zone for 15 minutes. The reported flow rate on the UI during the on time ranged from 190 to 224. Each UI update was different.

    I next reduced the pulse rate down to 0.5hz ( 1 pulse per 2 seconds). The reported flow rate on the UI ranged from 26 to 78. Approximately every other UI update was different. The magnitude of the flow rate variance limits the usefulness of this measurement capability. Is there a way to improve the measurement accuracy ?

    in reply to: How to Change sensor1 flow sensor input pin on pi zero2w ? #78126

    ronnie
    Participant

    I see now that “#define PIN_SENSOR1 14” does not actually refer to a physical pin. It refers to the header pin named GPIO 14 which is header pin 8.
    So, am I correct in assuming changing #define PIN_SENSOR1 “GPIO” 14 to something else in Defines.h is all that is necessary?

Viewing 9 posts - 1 through 9 (of 9 total)