[digitalbits]

Ok – I will look into those clients. I started and got working the Paho MQTT C/++ library and seems to be very reliable. Its pretty feature rich with means it won’t work on the smaller platforms most likely.

I need to add a couple options to the UI config screen and to get a feel for how this will work I have also submitted “part” of the first push request, to bind the raspberry PI interface to Local Host only. Option only shows up for RPI.

I was able to download the UI.zip file and run it locally and get things working fine to add one new option o52, hlh – for Http Local Host Only. I have not been able to find the UI code aartificats on GitHub. How do I contribute those changes back?

In the mean time, the option works great on the raspberry pi and is disabled on other platforms.
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/pull/77

[digitalbits]

@JimS I will in due time.

I wasn’t sure how active people were developing with this but I made changes that integrate well – but have not finished. For instance I’ve put put information in the code in a way that works for me but needs to be updated for config options which I’ve already started. Until that happens it just ends in a lot of confusion for people why it doesn’t work. I just got the hardware, so I’m just getting started.

There are already too many forks that get outdated. I don’t want to jump off in a direction that ends in yet another fork that is not maintained. 🙂 They will all end with pull requests and of course for the ambitious to go compile once I feel its ready to git.

[digitalbits]

No, I didn’t do that as I didn’t need them or really want them. Depending on the hardware, it shouldn’t be difficult but it could depend on what’s hooked up where. The i2c controller I used as part of the LCD I believe has a couple extra pins you can trigger things on but I didn’t want to spend the effort to wire it all up and further reverse engineer the software to make them work.

The LCD I used was from Amazon: Link

But DONT just hook it up! it does require some modifications for a i2c 3v3 vs LCD powered at 5v.

[digitalbits]

For those that are interested in LCD support, I did start to enable it natively within OSPI. It look some time to figure out the various components in the OS code, but I was able to pretty much get it all working without adding much code at all. If there is interest, I can issue a separate pull request for LCD support for the RPI. I’m still figuring out what other stuff I want to display on it and I’ve not put the options in the menu yet to enable/disable it and change the config.

I’ve also been working to enable MQTT support as well: MQTT Integration

What I used was a i2c connected 20×4 LCD. I snapped a couple pictures if you are curious what it looks like. I did have to modify the circuit a bit since they are really made for both 5v logic and 5v lcd.

Attachments:

1. 

   IMG_0454.jpg
   

2. 

   IMG_0455.jpg
   

[digitalbits]

I think what you have is pretty much the same thing as my initial post. One difference is wrapping the ‘data’ into a transaction type as if you subscribe to a parent topic, you will want to know what type of update it is (a station status update) for example. I have also changed things a bit, added weather update notifications, a heart beat to know that its alive and doing its thing and once per second updates when a zone/program is running which will also support flow sensor updates as well.

I have made significant progress – and actually have it working on my home sprinkler setup already. I’ve just got to add the options to the configuration pages to enable and provide a hostname. I also added i2c LCD support on the raspberry pi using a 20×4 LCD too and an option to have open sprinkler just bind to LOCALHOST so you can put it behind a reverse proxy (if you wish). I don’t know if Ray want’s all of this in a pull request or just the MQTT stuff. I got kinda carried away and added more features.

Ray – I guess a question for you would be what MQTT library is good to use on the raspberry pi? I know there’s a lot of code in OS that starts from an ESP type platform and is adapted or changed. To get started I just grabbed the embedded version of the PAHO-C MQTT library and used that. Is this acceptable? Should I look at an alternative library? I’ve abstracted the MQTT functions into a adapter class so it becomes pretty easy to make it portable to other devices based on whatever libraries we want to use, if different, vs changing them w/ #define statements.

[digitalbits]

Hey – I am just staring to use open sprinkler for the PI. I purchased the hardware and got everything hooked up and started to add MQTT support for the raspberry PI and noticed this post. I use MQTT for a lot of my home automation and was starting to add it. I want to make sure I’m doing this in a way which I can then issue a push request and have it brought into the product branch so want to get feedback or if it’s planning to be done and close to completing – then I’m not waisting my time.

I’ve not yet determined the control structures (turning on/off a station or program via mqtt). I would expect it to replace the last component of the topic below “status” with a command entry or something like that. The below is from a running instance were I’ve made a few tweaks and was able to get full MQTT working for the raspberry pi.

On the below I still need to work in the controller identifier or a hostname, should be a minor adjustment to account for installations w/ multiple main controllers.

The reporting structure that I was planning on using is as follows:

controller status information:
mqtt-topic : osprink/status
mqtt-payload: {“type”:”sensor_upd”,”data”:{“id”:0,”name”:”startup”,”action”:”startup”},”ts”:1530394707}

program start information:
mqtt-topic : osprink/pgm/0/status
mqtt-payload: {“type”:”pgm_upd”,”data”:{“id”:0,”name”:”My test program”,”action”:”start”,”adjpct”:38},”ts”:1530394860}

station start/end/status info:
mqtt-topic : osprink/sta/1/status
mqtt-payload: {“type”:”sta_upd”,”data”:{“id”:1,”name”:”My First Station”,”action”:”start”,”dur”:1},”ts”:1530394861}

mqtt-topic : osprink/sta/1/status
mqtt-payload: {“type”:”sta_upd”,”data”:{“id”:1,”name”:”My First Station”,”action”:”end”,”dur”:1},”ts”:1530394862}

mqtt-topic : osprink/sta/2/status
mqtt-payload: {“type”:”sta_upd”,”data”:{“id”:2,”name”:”S02″,”action”:”start”,”dur”:1},”ts”:1530394862}

mqtt-topic : osprink/sta/2/status
mqtt-payload: {“type”:”sta_upd”,”data”:{“id”:2,”name”:”S02″,”action”:”end”,”dur”:1},”ts”:1530394863}

mqtt-topic : osprink/sta/3/status
mqtt-payload: {“type”:”sta_upd”,”data”:{“id”:3,”name”:”S03″,”action”:”start”,”dur”:1},”ts”:1530394863}

mqtt-topic : osprink/sta/3/status
mqtt-payload: {“type”:”sta_upd”,”data”:{“id”:3,”name”:”S03″,”action”:”end”,”dur”:1},”ts”:1530394864}

mqtt-topic : osprink/sta/4/status
mqtt-payload: {“type”:”sta_upd”,”data”:{“id”:4,”name”:”S04″,”action”:”start”,”dur”:1},”ts”:1530394864}

mqtt-topic : osprink/sta/4/status
mqtt-payload: {“type”:”sta_upd”,”data”:{“id”:4,”name”:”S04″,”action”:”end”,”dur”:1},”ts”:1530394865}

sensor updates (weather, flow, and rain)
mqtt-topic : osprink/sensor/weather
mqtt-payload: {“type”:”sensor”,”id”:0,”name”:”weather”,”data”:{“action”:”update”,”adjpct”:38,”ts”:1530391894}}

Thoughts? Given Ray mentioned he’s considering this – do I continue? Is there a time line for it? I’m happy to contribute this back to the project if not.

[Author]

Posts