API question

[BobSutn]

I am writing a Java program using the OSPI API. My problem is that I don’t understand SBITS.

sbits : Station status bits. Each byte in this array corresponds to an 8-station board and represents the bit field (LSB).
For example, 1 means the 1st station on the board is open, 192 means the 7th and 8th stations are open.

My JSON query provides the following sbits info: “sbits”:[0,0,0,0,0,0], It appears to me that I have info for six 8-station boards for a total of 48 stations. I only have 40 stations, the main board provides 8 stations and two expansion boards provide 32 stations, for a total of 40 stations. I am assuming that I should only have five zeroes in the sbit field NOT six zeroes.

Can someone explain how to interpret the sbits field? Also, my interpretation of sbits is that [0,8,0,0,0,0] means that station 12 is now running which is indicated by the value of 8 in the above array. Is my interpretation correct?

[ShawnHarte]

The way the firmware works it will always use the MAX number of stations and extension boards. If you set a bit on a board that does not exist it will still schedule and “run” that station. So your hardware only has 40 physical stations available, but your device allows as many as 48. So the sbits field you are seeing is correct.
You are also correct in your assumption that station 12 has its bit set, and should be running.

Hopefully that explains what you are seeing,and clears up any worries you may have had about your setup. Just remember the firmware will always work with the maximum stations and extension boards that your particular device is capable of working with. This is done to keep the memory cleaned up and not have to rewrite all of it to adjust for future hardware changes.

[BobSutn]

It’s my understanding that the OSPI supports a maximum of 56 stations, the main unit supports 8 stations and a maximum of 3 expansion units each supporting 16 stations for a total of 56 stations. Thus, sbits should look like this “sbits”:[0,0,0,0,0,0,0] instead of looking like this “sbits”:[0,0,0,0,0,0]. There are 7 positions in the first sbits to account for all 56 stations whereas the second sbits only accounts for 48 stations. My gut feeling is that sbits should account for all 56 stations.

I completely understand your explanation and it makes sense. But the return value of sbits still has me confounded.

[Ray]

@BobSutn: make sure you are running the latest firmware because earlier firmwares only supported 48 stations for all OpenSprinkler platforms. Other than that, sbits should show 7 bytes for OSPi (it should show 6 bytes for OS 2.0 to 2.2, and 7 bytes for OS 2.3 and OSPi).

[BobSutn]

The Open Sprinkler Pi main controller board is marked as Version 1.43. The web page indicates that I am at firmware version 2.1.7 and app version 1.6.0. I did a fresh install of the firmware last week from the git hub site. I am using a Raspberry Pi 3 Model B with the OSPI main controller board.

[ShawnHarte]

Make sure the permissions on the nvm.dat file allow read and write, it almost sounds like the file wasn’t updated during the firmware flash. After you change the permissions make sure to restart the OS process.

[BobSutn]

I did a sudo chmod 755 nvm.dat.

Before attributes were -rw-r-r-
After attributes are -rwxr-xr-x

I rebooted the Pi after I changed the attributes and then executed the “Get Controller Variables” (jc) command which returned JSON string as follows:

{“devt”:1489593037,”nbrd”:5,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”41.16953,-75.87742″,”wtkey”:”***********”,”sunrise”:434,”sunset”:1150,”eip”:*********,”lwc”:1489591024,”lswc”:0,”lrun”:[0,0,0,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]],”wto”:{},”ifkey”:””}

I asterisked out a couple of variables for security reasons.

sbits is still at six variables.

[ShawnHarte]

The output is only showing you have 5 extension boards so the output is correct, 8*(nbrd+1). That’s 48 stations so 6 sbits is correct. If you actually have 6 extension boards attached one of them is not being read and is possibly a hardware issue.
I looked through the firmware and I don’t see anything that would cause the output to be incorrect software-wise.

Are you using official Opensprinkler hardware? I know sellers on Amazon have one, and if that is what you are using you may need to add a series resistor to their board to make sure it is detected properly.

****EDIT Okay never mind on that idea, the OSPi doesn’t use the detect function. So I would try renaming nvm.dat to something else and then rebooting again. It should recreate the file, and then you can check the board count again. If that changes I know where the problem is, if not I’m at a loss and would probably have to defer you back to Ray.

[BobSutn]

I am using official OpenSprinkler hardware. Main module and two expansion boards were purchased directly from Ray. I renamed the nvm.dat file but now I can’t access the system. I get a Unauthorized result code when I attempt to “Get Controller Variables” (jc). I also get a “invalid password” when attempting to login via the web page.

***EDIT*** I forgot I had to use the default password. I now get the following:

{“devt”:1489613584,”nbrd”:1,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”Boston,MA”,”wtkey”:””,”sunrise”:360,”sunset”:1080,”eip”:0,”lwc”:1489611924,”lswc”:0,”lrun”:[0,0,0,0],”sbits”:[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]],”wto”:{},”ifkey”:””}

[ShawnHarte]

Alright you can remove the new nvm.dat and rename the original back to nvm.dat, that should get you right back to where you were. It looks like the firmware does not properly write to the file when the firmware is upgraded. I’ll see what I can do about getting a fix proposed so at least the next version should write everything properly.

Thanks for your help, hopefully this gets things working correctly. Good catch by the way.

[BobSutn]

Just another observation.. When I successfully execute an API call, there is no result field in the returned JSON string. So, checking the result field will indicate a null value instead of a 1. The API documentation indicates that a 1 should be returned in the result field on success API execution.

[ShawnHarte]

Ya looking at the server.cpp file there appears to be a smattering of HTML_OK versus HTML_SUCCESS. OK will simply break the output before sending the result field. In this case checking the html header for 200 would suffice as a bandaid until I can get a change made and see if Ray or Samer will accept the pull.
SUCCESS will give the result:1 field that is to be expected when making a proper request for existing data.

It’s honestly a quick fix but the time it takes to get it accepted may be a bit. Once the pull request is up on github you could pull from my repository and merge the changes yourself. Or if you are half decent at programming take a look at server.cpp and for now just find and replace OK with SUCCESS and save it. Then build the firmware and you should be fine.

Some stuff will come back a bit odd like random text at the bottom of the password change page, but it shouldn’t break the program, just visual errors. The functionality will be the same as most of what’s happening in the firmware goes on before the result is printed.

[Ray]

I’ve lost track of this thread. The original question was to look for an explanation of why “sbits” has 6 numbers when it should have 5. I checked the firmware code:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/server.cpp#L900
and that reminded me that it always has a dummy 0 in the end. This code was from early versions of OpenSprinkler firmware, and it’s avoiding having to remove the last comma by simply adding a dummy 0 in the end. It’s lame and should be changed, but it explains why you are seeing an extra 0.

[Author]

Posts