Firmware 2.2.0(1) official released

[Ray]

Happy Holidays everyone! Following the release of the test firmware 2.2.0, today we have officially released firmware 2.2.0(1). On top of the features already available in the test firmware, this minor revision 1 has added a couple of new features, including supporting a custom device name that’s included in all IFTTT notifications, and supporting a new weather adjustment method called ‘Monthly’, which is similar to manual adjustment but allows you to set a different watering percentage per month. The full list of feature can be found in the Github release notes.

Since the test firmware was release last month, we’ve been fixing bugs and issues in both the firmware and UI, and also updating user manual, API document, and instructions on how to create and use OTC token for remote access. The OpenSprinkler mobile app and web UI have been updated to support OTC and all the other features. In addition, I’ve made a new video that goes through the main features of this firmware. Thanks for those users who reported bugs and issues which helped us to improve the software.

Now this firmware is officially released, as before, you can go to https://support.opensprinkler.com to find:

• A new video about firmware 2.2.0 at the bottom of this page
• User Manual 2.2.0(1)
• Firmware update instructions
• Instructions on remote access via OTC
• The article about how to use IFTTT to receive notifications have been updated to reflect the current IFTTT interface

If you have been using the test firmware 2.2.0, upgrading to minor revision (1) will preserve all your existing settings. We recommend you to go to http://your_os_ip/su and change the Javascript url back to https://ui.opensprinkler.com (the test firmware has been using testui.opensprinkler.com). If you don’t, that’s not a big deal, the testui is currently synchronized with ui, so you shouldn’t see the TEST BUILD banner any more.

As the firmware is still pretty new, we expect more bugs/issues will be discovered as users start to use it. If you encounter any problem, please be patient and file a support ticket at https://support.opensprinkler.com. We will try to address them as soon as possible. Also remember you can always downgrade to the previous firmware if you dislike the new firmware. Thank, and again, Happy Holidays!

[tonyc]

Thanks for the update Ray. I just watched the 2.2.0(1) video and I love the new features. Just one question from me, is there a chance that OpenSprinkler PI will have the ability for remote cloud access in the future? Port forwarding is not possible to my home as I have an LTE connection and so the only option is to have Cloud access via OTC. Thanks!

[Ray]

https://opensprinkler.com/forums/topic/otc-support-for-ospi/#post-74467

[Ant]

Thanks for this update Ray. Installed with no problem but when importing my old configuration the software hung. This was similar to what I experienced with the test version of 2.2.0. The solution provided by your team is to do a factory rest, then edit out the MQTT line in the backup JSON file, ie “mqtt”:{“en”:1,”host”:”XXX.XXX.XXX.XXX”,”port”:1883,”user”:”XXXXX”,”pass”:”XXXXX”},
Once this was removed the import ran smoothly and I now have 2.2.0(1) up and running.
Thanks for the continued development.

[Ray]

@Ant: yes I aware of that. It turns out that because the firmware will immediately start to connect to MQTT server when that part is imported, it will stop responding to the rest of the import request. So I am aware of why this is happening. One way to fix this is to require a reboot before enabling MQTT, but I feel probably only a small number of users would encounter this so I decided to leave it as is and let them know the work-around if this happens.

[dun4cheap]

So I updated one of my 3.0 controllers and now it no longer works with my app as wher all of my other controllers do. I use the api calls to set rain delays and backup my settings of all 21 of my active controllers. So I am not sure what has changed. I jave tried /ja and /jc as well. I used Visual Basic and the winsock.ocx.

get /cv?pw=md5password HTTP/1.1/ now returns this.

HTTP/1.1 413 Request too large

The request was too large

This is what I get from FW 2.19
{“settings”:{“devt”:1673968964,”nbrd”:5,”en”:1,”sn1″:0,”sn2″:0,”rd”:1,”rdst”:1673991520,”sunrise”:412,”sunset”:1027,”eip”:2728279905,”lwc”:1673959637,”lswc”:1673959637,”lupt”:1673359597,”lrbtc”:99,”lrun”:[39,1,-15976,1673938021],”mac”:”xxxxxxxxxx”,”loc”:”33.91848,-118.13824″,”jsp”:”https://ui.opensprinkler.com/js”,”wsp”:”weather.opensprinkler.com”,”wto”:{“baseETo”:0.197,”elevation”:600,”key”:””},”ifkey”:””,”mqtt”:{},”wtdata”:{“wp”:”DS”,”eto”:0.053,”radiation”:1.16,”minT”:51,”maxT”:59,”minH”:74,”maxH”:94,”wind”:9.8,”p”:0.97},”wterr”:0,”curr”:0,”sbits”:[0,0,0,0,0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]]},”programs”:{“nprogs”:4,”nboards”:5,”mnp”:40,”mnst”:4,”pnsize”:32,”pd”:[[1,127,0,[12293,0,0,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,65535],”Lights Ct 16″],[3,41,0,[1320,3,10,0],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,240,240,0,180,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”noche”],[3,45,0,[1170,3,60,0],[240,330,0,60,0,0,300,300,240,360,0,240,240,0,0,0,180,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”nuebo 3x”],[1,91,0,[900,0,180,0],[180,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,120,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”Program 4″]]},”options”:{“fwv”:219,”tz”:16,”ntp”:1,”dhcp”:0,”ip1″:192,”ip2″:168,”ip3″:3,”ip4″:15,”gw1″:192,”gw2″:168,”gw3″:3,”gw4″:1,”hp0″:80,”hp1″:0,”hwv”:23,”ext”:4,”sdt”:0,”mas”:0,”mton”:0,”mtof”:0,”wl”:0,”den”:1,”ipas”:0,”devid”:0,”dim”:50,”uwt”:131,”ntp1″:0,”ntp2″:0,”ntp3″:0,”ntp4″:0,”lg”:1,”mas2″:0,”mton2″:0,”mtof2″:0,”fwm”:9,”fpr0″:100,”fpr1″:0,”re”:0,”dns1″:192,”dns2″:168,”dns3″:3,”dns4″:1,”sar”:0,”ife”:0,”sn1t”:0,”sn1o”:1,”sn1on”:0,”sn1of”:0,”subn1″:255,”subn2″:255,”subn3″:240,”subn4″:0,”wimod”:169,”reset”:0,”dexp”:4,”mexp”:8,”hwt”:172},”status”:{“sn”:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”nstations”:40},”stations”:{“masop”:[255,255,255,255,255],”masop2″:[0,0,0,0,0],”ignore_rain”:[0,0,0,0,128],”ignore_sn1″:[0,0,0,0,0],”ignore_sn2″:[0,0,0,0,0],”stn_dis”:[0,0,0,0,0],”stn_seq”:[255,255,255,255,127],”stn_spe”:[0,0,0,0,0],”snames”:[“S01″,”S02″,”S03″,”S04″,”S05″,”S06″,”S07″,”S08″,”S09″,”S10″,”S11″,”S12″,”S13″,”S14″,”S15″,”S16″,”S17″,”S18″,”S19″,”S20″,”S21″,”S22″,”S23″,”S24″,”S25″,”S26″,”S27″,”S28″,”S29″,”S30″,”S31″,”S32″,”S33″,”S34″,”S35″,”S36″,”S37″,”S38″,”S39″,”S40 Lights Court 16″],”maxlen”:32}}

[Ray]

Firmware 2.2.0(1) has a restriction where the incoming request header cannot be more than 2048 bytes long. Typical request headers are way less than 2048 bytes. It’s possible whatever script you are using to send the request is imposing a long header. You can check that.

I am not sure what
get /cv?pw=md5password
does. It seems to call cv with only a password but no other parameter.

[dun4cheap]

In the following, updated or newly introduced JSON variables are highlighted by green color .
3. Get Controller Variables [Keyword /jc]
/jc?pw=xxx

In a browser you would put http://os-ip/ja?pw=

when putting it through a socket you connect and send get /os-ip/ja?pw=md5password

These commands worked up until the new firmware. This same call works on fw2.19 and below. I did not try the 2.2.0 fw, but I installed the 2.2.0(1) and it now returns this

HTTP/1.1 413 Request too large

The request was too large

So something more has changed.

[dun4cheap]

Here is some more info regarding http get and post

HTTP Request Methods
What is HTTP?
The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers.

HTTP works as a request-response protocol between a client and server.

Example: A client (browser) sends an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.

HTTP Methods
GET
POST
PUT
HEAD
DELETE
PATCH
OPTIONS
CONNECT
TRACE
The two most common HTTP methods are: GET and POST.

The GET Method
GET is used to request data from a specified resource.

Note that the query string (name/value pairs) is sent in the URL of a GET request:

/test/demo_form.php?name1=value1&name2=value2
Some notes on GET requests:

GET requests can be cached
GET requests remain in the browser history
GET requests can be bookmarked
GET requests should never be used when dealing with sensitive data
GET requests have length restrictions
GET requests are only used to request data (not modify)
The POST Method
POST is used to send data to a server to create/update a resource.

The data sent to the server with POST is stored in the request body of the HTTP request:

POST /test/demo_form.php HTTP/1.1
Host: w3schools.com

name1=value1&name2=value2
Some notes on POST requests:

POST requests are never cached
POST requests do not remain in the browser history
POST requests cannot be bookmarked
POST requests have no restrictions on data length

[Ray]

There are two places where the OTF library may throw out the 413 error:
https://github.com/OpenThingsIO/OpenThings-Framework-Firmware-Library/blob/master/OpenThingsFramework.cpp#L102
https://github.com/OpenThingsIO/OpenThings-Framework-Firmware-Library/blob/master/OpenThingsFramework.cpp#L120

If you try the request in the browser, do you still get the 413 error? I feel it may have to do with you using a socket for the GET request.

[dun4cheap]

Ray, There is definitely something with the firmware. That is behaving differently causing this response. Nothing has changed with the microsf winsock control, it is still working without fail on previous firmwares.

[Ray]

Well, you are not providing enough information for us to help you. Yes, the firmware is different, of course, but I don’t know how to debug to help you. Maybe at least you can take a look at the header that your winsock control is sending out? Also the firmware code is publicly available, so you can compile it yourself and debug it on your side.

[carride]

Thanks Ray.

One minor note: The https://openthings.freshdesk.com/support/solutions/articles/5000716364-user-manuals page defaults the link to the OSUserManual220(1).pdf as http, so is less secure. At least in Firefox browser there is a security warning when clicking to download. It is simple for the user to change to HTTPS manually, though better if you change the 5000716364-user-manuals page to explicitly say https, or have your raysfiles.com server force redirect to https. Or move the PDF to Freshdesk server. This issue does occur for old manuals which are hosted on the same server as the 5000716364-user-manuals page at freshdesk

http://raysfiles.com/os_compiled_firmware/docs/2.2.0/OSUserManual220(1).pdf

[Ray]

Thanks for pointing it out. It has been fixed now.

[dun4cheap]

Ray, The header info I supplied and the info that I am getting back from the OS Controller with FW 2.2.0 does not really give me anything I can go off of. If there a log available on the controller itself I can get. I could supply you with my app. The msWinsock ocx is an activex control that comes with Visual Basic. I am simply setting the port to 80 and connecting to the open sprinkler IP and sending the Get command. I get the proper response back from OS FW2.19 and below. Just not the 2.2.

Let me know if want to try it or if their is a way to get the log from the OS controller.

[Ray]

dun4cheap: unfortunately I haven’t used Windows for like a couple of decades… Is that really your only option? Can you not use like Javascript or something more modern?

I suppose you can access the controller with the mobile app or in a web browser, is that correct? That means the HTTP GET request is working. Why it has an issue with your msWinsock osx, I really have no idea.

[cybergrimes]

(reposting; original seems to have disappeared… sorry if this becomes a double reply)

Question about “NEW from OpenSprinkler v3.2: from v3.2, the controller has dual support for WiFi and wired Ethernet.” which as far as I can see is related to 2.2.0(1)s update to ESP8266 WiFi Core 3.0.2 and lwip as wired Ethernet library.

I’m using ethernet. After upgrading firmware I’m seeing the AP mode running even when the ethernet interface was connected. I had the device join my wireless network expecting “When the Ethernet module is plugged in, the controller boots in wired Ethernet mode; when the module is unplugged, it boots in WiFi mode.” However instead I’m seeing the device connected on both interfaces at the same time. I can access the UI at both IP addresses.

It’s not consistent though; ethernet has been connected for 9 days but wifi connected 5 hours ago. This is the exact time of my nightly “:>reboot” program. The last time it connected via wifi (per my access point console) was 1/28 during the reboot cycle.

[spanno]

Hi ray,

Thanks for the new firmware, it offers a lot of useful functionalities, I suspect a lot of work went into it!

Just one thing that doesn’t seem to work for me: OTC through Android App.

I am on an internet connection in a remote area. My network provider uses different layers of NAT (Network Address Translation). In the past I have never gotten any Dynamic DNS services or port forwarding working (for Opensprinkler or any other service within my network).

I was hoping OTC for Opensprinkler would work, and it does, BUT ONLY when I access my Opensprinkler remotely through the webinterface on https://ui.opensprinkler.com/

When I try to connect remotely (mobile 4G) through the Android App (2.3.0, firmware 2.2.0(1) HW version 3.2DC) I get an “unable to connect” message.
When I connect remotely through my home Wifi network (using the token). the App does connect to my Opensprinkler flawlessly.

it is not a very big deal for me, although it would be nice to be able to access Opensprinkler out in the field, without having to walk back to my WIFI network;)

*edit: well, actually I can access through the webinterface, so I don’t have to walk back;)*

any suggestions you might have on resolving this are very welcome!

thanks for all the good work!

[Ken.238]

I try to compile from arduino ide and get an error OpenthingsFramework.h no such file or directory. I also try on platformio and the error pio\build\d1_mini\firmware.elf. Do I missing something? Thanks .

[D N]

Hello,

Is it still possible to host the javascript files on a local webserver with this firmware release?
Where exactly are the javascript files please? I’ve not been able to find them again (I imagine they’ve been changed?).

Thank you!

PS: Found instructions at the bottom of this repo’s readme, but the javascript bundle can’t be downloaded any longer: https://github.com/OpenSprinkler/OpenSprinkler-App

[Ray]

Which javascript bundle are you referring to?

In most cases you don’t need to change the javascript url anymore. You can download the app repository, unzip it, then open index.html in the www subfolder. This is how we test and debug the app UI.

[D N]

The bundle which used to have to be downloaded to be hosted from a local web server to avoid needing to be online to use OSPi.

Anyway, if it has all changed, are there instructions on how to host/run the App component please? I’ve followed the upgrade guide but saw no mention of a separate App component sorry.

I have an OpenSprinkler Pi and wish to host the app with HTTPS/TLS.

Thank you!

[terryhonn]

Hi all –

I’ve tried upgrading one of my RPi Opensprinklers to this firmware, following the directions provided here: https://openthings.freshdesk.com/support/solutions/articles/5000631599

But the web interface continues to show 2.1.9(3), and the Pause and Grouping functions, for example, are not there.

Should I export my config again, blow away the entire OS filestruction, service, etc., and start over?

Thanks for any guidance!

[Ray]

You can just delete your existing firmware folder, and follow the instructions to install firmware from scratch.

[terryhonn]

Dang it Ray! I know I’d tried that already! But it worked this time, because you said it would. 🙂

Thanks so much, don’t mind me.

[Author]

Posts