- This topic has 15 replies, 6 voices, and was last updated 5 years, 4 months ago by
.
-
Posts
-
Hi,
I was delighted that firmware 2.1.7 introduced HTTP stations for OpenSprinkler 2.3. This is super useful for combining OS with pumps controlled by Home Automation systems, such as Z-Wave based setups. Thanks!
However, there is an URL length limit that prevents usage in many real-life scenario. Example: For Domoticz (a popular Open Source Home Automation solution), the URL to switch a switch is:
/json.htm?username=VGVzdHVz&password=VGVzdGluZzEyM2Rm&type=command¶m=switchlight&idx=11&switchcmd=On
Turns out this doesn’t work – it’s too long. The length limit seems to be overall (including “Server name”, “Port” and “On command” / “Off command” – that is, if you have a short “Server name”, you get a few extra characters for “On command”).
Aside from the fact that the length limit is too low for practical usage in many scenarios, the behavior when the limit is exceeded is erratic. There’s no message like “URL too long”, it just either truncates the URL, or causes the system to crash irregularly. Once I even had to do a factory reset to recover from my “max URL length” experiments.There’s also one limit for it to work (appears to be ca 184 characters for server+port+On URL+Off URL), and an even lower limit for configuration restore via JSON upload to work (the “Off command” will be set to undefined on restore).
All the best,
TillTill,
Thanks for the feedback on the HTTP Station code. I have to put my hand up here as the guy responsible. I submitted a PR to Ray and Sammer last year for this as a simple extension of the Remote Station code. I recognised the space limitation of circa 250 characters across all parameters. This is a design template constraint where parameters for Special Stations get processed within the OpenSprinkler working buffer (~250 bytes). Using the existing design pattern meant for a simple implementation but with a knock-on constrain. This is ok in many cases but falls down when you need to authenticate as username/passwords push out the character count!
Nowadays, many browsers/services are moving away from encoding username/password in the URI and are using html headers to carry the authentication. So I saw this as more of a need to add authentication headers in the future rather than needing to extend the command length (good bit of post-rationalisation 8).
The defects on the other hand aren’t great. Thanks to your investigations, I have replicated the issues above and have seen that the length checking I do is too late in the process i.e. I check lengths in the Firmware after decoding the html message from the App. This is too late to catch the buffer overrun and inform the user. I have a fix that I’ll package up and submit.
In terms of immediate options, I have seen that Domoticz allows you to remove authentication if that is acceptable. No good if you are allowing remote access but might be OK if everything is behind your router firewall? Alternatively, I see Domoticz also allows you to whitelist a network (i.e. waive the authentication if sourced from a known secure network). On their Setup/Settings page you have “Local Networks (no username/password)” field into which you could add 192.168.0.*, or equivalent, to waiver authentication for the local network. Not sure if that helps but I’ve just tried it out and it seems to work.
As I say happy to take feedback on importance of this feature and whether authentication/command length is something in demand. To be honest, I didn’t think many others where using this mode and glad to see that there is some interest in it. Let me know your thoughts and I’ll try to improve the implementation.
Thanks, Pete
Hi Pete,
thanks for the quick reply! Domoticz allows both, user/pass in the URL, or using HTML headers. Obviously, I had to chose the “URL” way since OS doesn’t support username/password in HTTP headers.
I think your tip to use “Local Networks (no username/password)” is very good. I’ll just set it to the OS IP, and will report back if it actually works.
Oon a side note, over night OpenSprinkler crashed again, so even at 184 chars there appears to be an issue.
All the best,
TillHi,
update: The “Local Networks (no username/password)” suggestion for Domoticz users works: also the HTTP JSON API works without password if this option is used. It is possible to add specifically only the OS IP address as “Local Network” instead of a range. Only disadvantage: This setting is not per-user, but global; anybody with the specified IP (range) will have full *Admin* rights in Domoticz (but then again… if an attacker is already in the position to spoof IPs in your local network, you have major issues anyway…)
Will report again in a few days if this also solves my stability issues that came up after firmware update + using long URLs for switching.
Thanks again Pete!
All the best,
TillI tried unsuccessfully to set up a http station by putting <username>:password@<IP Address> in the server field and then putting my commands in the on and off fields. In the mean time I put a php file on a local web server to act as a go-between. It would be nice to accomplish this directly and eliminate having to go through another device. The device I am trying to communicate with is an ISY994i. It cannot be set up to work without a username/password.
Thanks
For others, the server field expects a server identifier as either an IP address or a hostname. There is no support for url encoded authentication via the server field. As the above post points out, supplying “<username>:password@<IP Address>” into this field causes OpenSprinkler to look for a device named exactly that on the network and fails.
The “man-in-the-middle” approach suggested above is a good workaround where authentication is needed but requires an available web server. For those using OSPi, you can install the apache server onto your existing OSPi raspberry pi to leverage this option without needing additional hardware. Not the ideal but a way forward…
Hi
I am using following version of Opensprikler on RPi:App Version: 1.7.7
Firmware: 2.1.8(1)
Hardware Version: OSPiI am still having problem with saving remote station configuration. When I try to save it via Browser or App as on first attached image: ON and OFF command is replaced by “undefined” and server url change to strange format (first attachment).
When I try to something different: export configuration file and edit it text editor and place the Http station as follows:
192.168.1.110,8080,json.htm?type=command¶m=switchlight&idx=99&switchcmd=On,json.htm?type=command¶m=switchlight&idx=99&switchcmd=Off
After import of the file I receive proper server url, proper port number but in the On command I have only: “json.htm?type=command” and in the Off command: “undefined” (second attachment).
Is there any solution for this problem?
treb0rAttachments:
@trebOr, I cant replicate the problem with the first attachment but I’m using slightly different versions to you so I will upgrade to the equivalents and test a bit more. Can you take a screen shot of the populated station dialog “before” you hit submit so that I can see what you are putting into each field. Can you then wait for 60 seconds and then re-open the dialog to see if the contents are correct. You need the pause as the App takes a while to reload data from Firmware.
I can replicate the second attachment and it looks like the App import functionality works differently to the station settings dialog. The import code does not uri encode the special station configuration data before sending across to Firmware. As a result, the Firmware parser sees the first “&” in the on command and thinks that’s the end of the station config. Hence you get a truncated On command and an undefined Off command. This is probably down to me as I think the HTTP Station is the only place where you need nested encoding. I’ll submit a fix into OpenSprinkler-App as soon as I get some time.
If you need an interim work-around, and are comfortable with linux command line, then you could edit the stns.dat file in the pi home directory to contain the right configuration. This is a binary file so you would need a HEX editor (
sudo apt-get install hexedit). Let me know and I can tell you more on this.[apols if duplicate post but forum disappeared the first response]
I managed to edit stns.dat file and it seems to be workind as it should. Until update I will not be changing and saving anything 😉
Thanks
treb0r@treb0r, I have upgraded to the latest versions of App and Firmware and can now replicate your first attachment error.
I can see here that the urlDecode() line has now been commented out of Firmware but not out of App. So you get the behavior you are seeing above (i.e. the %2C sequence is not being decoded back to a “,” delimiter). Looks like it was a conscious decision to remove the decoding but I’m not sure why. You have the option to edit stns.dat directly but, as you say, be wary of updating/saving.
Linking in github issue 70 that is tracking this.
If I remember it correctly, the original code applies decoding when the firmware receives the HTTP command from the UI, and stores it, and then encodes it when using it in the switch_httpstation function. I thought there is no need to do this extra level of decoding and then re-encoding it, so removed both. This way, the firmware merely receives and stores an already encoded command, and uses it inside switch_httpstation function.
Quick update: I figured out the issue, see my last comment here:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/issues/70
will be fixing it right away.
Has this issue been resolved yet? Currently encountering same issue as described :
https://opensprinkler.com/forums/topic/bug-http-stationos-2-32-1-7-url-length-limitation-causes-erratic-behavior/#post-51146with the url:
http://192.168.2.217/cm?user=admin&password=ThePassword1&cmnd=PowerOnand any variation of it, using
App 1.8.2
FW 2.1.8Thank you.
Thanks Ray, does that mean the 3.0 OS firmware or in app? And assuming itll be a while before its pushed to unified firmware?
thanks again
—————
edit-updated:Using an RPI3 for my OpenSprinkler, following the Guide here: https://openthings.freshdesk.com/support/solutions/articles/5000631599-installing-and-updating-the-unified-firmware I was able to easily update my firmware from 2.1.8 to 2.1.8(2) and the http bug is fixed for me.
for anyone using a sonoff, the http port setup would be like:
station type: http
server name: <your ip address>
server port: <port that leads back to 80 on your sonoff>
on command: cm?user=adminname&password=yourpassword&cmnd=Power%20On
off command: cm?user=adminname&password=yourpassword&cmnd=Power%20Offopensprinkler inserts the “/” for you, and the “%20” needs to be in there via sonoff api
turning the sonoff off by hand or by the GUI, while its supposed to be running within OpenSprinkler, Opensprinkler just turns it back on, no indicator that its been turned off or visually let you know the station is off. Just turns it back on.
no complaints, just informing anyone that’s curious.
@matt: ok, thanks for the update.
- You must be logged in to reply to this topic.