Feature Requests: control OSBee programs from ha-osbee

[gitwob101]

I would like to be able to control programs from within Home Assistant. In my setup I have switches that run for a short time only because they feed water to containers. For example, a 20 minute timeout is way too long and will flood these containers. I am typically enabling this switch for 15-60 seconds, and maybe several times with a delay of something like 5-10 minutes. On another switch I am using drip tape which needs to run for much longer than the default max of 20 minutes. I run for 19 minutes x 6 for 2 hrs.

It would be useful to be able to enable/disable or run existing programs in OSBee from HA. The intention is to achieve a manual rain delay by interacting with a button/etc. in HA. This can also form the basis of having HA, if detected rain (by means unrelated to OSBee), then automatic disable OSBee programs via HA, or vice versa if clear skies.

The reason to have HA control programs as opposed to programming OSBee and performing all actions from HA is that I relying on OSbee, and embedded control, seems more reliable when away from the physical location for some time (a week). There are any number of reasons as to why access to HA could be lost (dynamic IP changes, VPN issues, HA issues, failed wifi network, etc.) but the OSBee device will continue to do its thing on schedule. If there are technical issues, all things being equal, water plants during rainy period is prefer to no water at all during a dry period. Rain delay with HA, or even manual intervention is preferable, but things happen.

Also not that since I am managing OSBee switches with programs that are being re-run in succession, disable ha-osbee switches is only an intermittent change as OSBee turns them back on with the next program iteration. Off-cycle watering for containers is straight forward as can run for 15 seconds via HA (this could be a timed button in HA as well), but off-cycle for the drip tape will only be 20 minutes, as opposed to multiple iterations if I decide to, say, water in the evening when I am only on an AM OSBee watering program.

That's my user story, and I am sticking to it :)

[chickenandpork]

The osbee has a default program time, but you can still turn it on and off.

for example, you can build an automation that:

1. Turn on switch (valve)
2. Delay 20 seconds
3. Turn off switch

This should work just fine with any switch, including osbee, and you don’t need to change the default program duration.

otherwise, the fix would be exposing a config value to change the default program duration, and I’m happy to do it, but the basic 3-step automation should work for you now

Can you give it a try, tell me how it works?

[chickenandpork]

@gitwob101 ^^ tagging you to ensure GitHub lets you know.

Although the above would let you have the same control on your system that I have in mine, re-reading your feature-request, it seems you actually want more of a way to define and apply new schedules that the OSBee runs independently? If that's the case, what would that look like? I don't mean to argue, I'm looking for an idea of how that would work best for you.

[gitwob101]

I have implemented some schedules via Home Assistant which should get me where I need to now.

My original ask was have Home Assistant call the OSBee API to enable or disable OSBee programs, or to be able to "run now". The "run now" is mostly the same effect as calling an automation from HA. The problem that I was trying to solve is to conveniently disable a program in the event of rain.

The problem that I am trying to solve is to make watering reliable and choose the most resilient path so I we away for a week, etc.. For example if there was a power outage that exceed my UPS capacity, the OSBee could potentially continue as it can be run on its own power bank. It is located away from my IT/network stuff as it is close to the water source so requires this anyway. If the infrastructure running HA failed, OSBee would continue to keep trucking.

I am not an engineer, but my thought is that HA is left for the bells and whistles, and let OSBee be its own fail save. The stakes aren't actually high as this is an attempted to growing a small quantity of backyard vegetables (this is not a farming operation), but I also rather not lose things because HA decides to fail for some reason (operating VMs/containers much more complex than an embedded controller). HA on its own embedded hardware? Maybe but that is not a summer project for me, and also negates the whole point of consolidating my IT stuff.

Context: I live in the GTA in Ontario, Canada. We get a spurt of hot summer periods where I will need to provided additional watering. Despite being a "word class" city, the area that I live in doesn't have the most stable electrical supply. My UPS devices squawk regularly, and we do get brown outs and the occasional power outages more regularly than is reasonable, and sometimes seemingly quite randomly.

[chickenandpork]

I have implemented some schedules via Home Assistant which should get me where I need to now.

:)

Context: I live in the GTA in Ontario, Canada. We get a spurt of hot summer periods where I will need to provided additional watering

This makes a bit more sense. Although I'm currently in Victoria, BC, I had a few years in Kingston, commuting into TO for meetings, I can point at what those summers are like :) I like your notion of trimming the dependencies down to just the program that OSBee independently runs.

It might be possible to convert this to a different sort of module:

• some sort of "set a value" for a program
• expose schedules as switches that allows you to activate/deactivate a schedule
• some sort of "run now" similar to what is this integration does for one-off runs

Conversely to building a way to push out schedules, if the schedules don't change often, Terraform might suffice (if you haven't use dit, you can read some values, derive a value, and store that back in via a basic REST. This would perhaps let you set schedules. I run terraform "apply" to push out configs in GitHub Actions that use a GitHub-runner running on my NAS.

[chickenandpork]

@gitwob101 looking for your thoughts on how this module can dramatically change together you what you're looking for ^^

[gitwob101]

Can we start with enable/disable each of the 6 program schedules?

[chickenandpork]

Can we start with enable/disable each of the 6 program schedules?

Simple switch on/off ? IIUC, this would result in a jp to read program data, and a cp to send a change -- the only change is that the enable bit in the first byte of the "config" value toggles on or off... sound correct ?

I want to confirm: the API I see offers up to 32 programs, not 6, so I want to be fairly certain. (I'm not connected to "Ray", who builds these)

[gitwob101]

Hi, I can't speak to this question. In the UI, under "Programs" I see 1-6.

[chickenandpork]

Hi, I can't speak to this question. In the UI, under "Programs" I see 1-6.

Hey. Sorry, missed this reply as well :(

OK, so we're looking at it from very different sides :) I want to ask some questions but I don't want to sound obnoxious or rude. Also, my memory is bad, so I may re-ask questions(sorry), but I don't see us going to this detail in the history.

Are you comfortable running a python program ?

Have you used "curl" or "wget" programs?

If you're OK with curl and your OSBee was on IP 10.1.2.3, can you share me the result of:

curl -vL http://10.1.2.3/jp

Finally, if your Device Key on your OSBee was "chicken" does this activate your second program (of course, replace "chicken" with your actual device key) ?

curl -vL http://10.1.2.3/rp?dkey=chicken&pid=1

[gitwob101]

Here you go:

curl -vL http://192.168.2.33/jp
*   Trying 192.168.2.33:80...
* Connected to 192.168.2.33 (192.168.2.33) port 80
> GET /jp HTTP/1.1
> Host: 192.168.2.33
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: application/json
< Access-Control-Allow-Origin: *
< Content-Length: 511
< Connection: close
< 
* Closing connection
{"tmz":32,"progs":[{"config":32609,"sts":[360,5,30,-1,-1],"nt":1,"pt":[445441],"name":"Horseshoe AM"},{"config":65634,"sts":[300,3,5,-1,-1],"nt":1,"pt":[15362],"name":"Patio AM 5:00"},{"config":32608,"sts":[330,3,5,-1,-1],"nt":1,"pt":[15364],"name":"Front 05:30"},{"config":32737,"sts":[1200,5,30,-1,-1],"nt":1,"pt":[445441],"name":"Horseshoe PM"},{"config":32608,"sts":[1020,3,5,-1,-1],"nt":1,"pt":[15362],"name":"Patio PM 17:00"},{"config":32736,"sts":[1050,3,5,-1,-1],"nt":1,"pt":[15364],"name":"Front PM"}]}

Second one:

curl -vL http://192.168.2.33/rp?dkey=redacted&pid=1

Trying 192.168.2.33:80...
* Connected to 192.168.2.33 (192.168.2.33) port 80
> GET /rp?dkey=redacted HTTP/1.1
> Host: 192.168.2.33
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 500 OTF error
* Header without colon
* Closing connection
curl: (8) Header without colon

[1]+  Exit 8                  curl -vL http://192.168.2.33/rp?dkey=redacted

[chickenandpork]

Hey @gitwob101

...
curl -vL http://192.168.2.33/rp?dkey=redacted&pid=1

...
< HTTP/1.1 500 OTF error

• Header without colon
  ...

I think there's something confusing the parser at your OSBee; do you have special characters in your password? You might need to URL-Encode it. If you don't have a handy too to do that, loo at https://www.urlencoder.org

"OTF" seems to be "Open Things Framework", so the error seems to be coming from deeper in the OSBee code. The only thing that I can't see looking free of risk would be your dkey. Of course, I don't want to know your key, but you might be able to URLEscape or URLEncode it to avoid parsing until it's copied to parameters.

[chickenandpork]

FWIW, I've been able to trigger a stored program in the underlying library:

• the library has an examples/dump_status.py
• changes there can show programs, and I'm manually triggering the first program

I'll work soon to make these actions available as .. I guess switches, one per program, that show status "on" once activating a program, and will remain "on" until the program completes (ie valves all closed) or any of the switches for individual valves is triggered (which replaces the running program with a "77" or "Manual" program (OSBeeAPI-1.0.0 section 11 bullet 2) )

Still in-progress