This topic contains 18 replies, has 9 voices, and was last updated by  Ray 3 weeks ago.

Viewing 19 posts - 1 through 19 (of 19 total)
  • Author
    Posts
  • #48248

    ruimarinho
    Participant

    Hi,

    I’m trying to integrate OS 3.0 with Home Assistant but unfortunately the REST api requires polling which does not provide the best user experience due to the requirement of using polling to get updated data.

    Are there any plans to offer more advanced data sync capabilities such as MQTT? I’ve been using espurna for other esp8266-based devices and its MQTT support is incredibly good.

    Thanks!

    #48410

    Ray
    Keymaster

    Not yet. Have been working on integrating Jeff Lawrence’s improved OpenGarage firmware, which does integrate MQTT for OpenGarage, and the same feature can be integrated into OpenSprinkler. I’ve put it on todo list now.

    #49483

    perscheid
    Participant

    Hello Ray,

    what is the state of the mqtt integration. I am already waiting impatiently. Thanks for your answer.

    Greetings Micha

    #49989

    Ray
    Keymaster

    Haven’t made any progress on this yet. Would appreciate if someone familiar with MQTT can take the leap to get this started, or at least make some suggestions/recommendations about how they want to integrate MQTT.

    #50599

    alexsahka
    Participant

    Hi Ray,
    I’m waiting for MQTT integration as well, to use it with NodeRed or with any other software.
    And I have a question, currently, I’m using OpenSprinkler API to log activity to a database with Node-Red, and I call HTTP API GET command every 15 sec, is this unhealthy?
    Could you confirm, is this OK?

    #50683

    Ray
    Keymaster

    Every 15 sec is fine — the OpenSprinkler app or web UI pulls data every 5 seconds, so it’s even more frequent.

    We will try to get the initial MQTT implementation in for the next firmware — on OpenGarage, which is another product we sell, we did integrate MQTT in the last round of firmware, so it shouldn’t be too hard to add it for OpenSprinkler too.

    #50900

    digitalbits
    Participant

    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.

    #51019

    Ray
    Keymaster

    Yes please continue. Any contributions you make will definitely help. Thanks!

    #51707

    ruimarinho
    Participant

    That look like a great start! I would definitely love to see this on the next firmware update 🙂

    Having used Home Assistant for a while, I would just keep it very simple: a state subtopic for each station, i.e. opensprinkler/station/4 with the following payload sent with the RETAIN flag:

    
    {
      "state": "on",
      "name": "My First Station",
      "duration": 10,
      "updated_at": 1530394861
    }

    Then another subtopic for setting station data, i.e. opensprinkler/station/4/set:

    
    {
      "state": "off",
      "name": "New Station Name",
      "ignore_rain": true,
      "sequential": false,
      "enabled": true
    }
    

    Main controller settings could be updated using the opensprinkler/set topic, probably on a 2nd phase.

    • This reply was modified 1 year, 1 month ago by  ruimarinho.
    #51711

    digitalbits
    Participant

    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.

    #51808

    Ray
    Keymaster

    For OpenGarage we used pubsubclient which is a pretty common library for the Arduino (including ESP8266) platform. I haven’t looked into if this is available for OSPi, I would assume so (since most Arduino libraries are also available for OSPi) but I should probably done some research before making a claim.

    #52062

    ruimarinho
    Participant

    The usual suspects are PubSubClient for synchronous and AsyncMqttClient for asynchronous style.

    #52522

    digitalbits
    Participant

    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

    #52735

    Ray
    Keymaster

    You do not have to modify the app code for now — if you just need to have a page for users to set configuration parameters, you can create an adhoc page (this is how OS 3.0’s firmware update page is done: you have to manually type http://x.x.x.x/update to get to that page as it’s not integrated into the app, but at least it doesn’t require modifying the app code).

    #53975

    [email protected]
    Participant

    Hello,

    are there some news about the mqtt integration?
    With mqtt support, opensprinkler would be my first choise.

    Regards

    #61735

    bloemeschier
    Participant

    Also seriously interested in this topic. I don’t like the entire IFTT integration as I just want to have a connection from OpenSprinkler directly to my local domotica software. So any progress so far?

    Cheers,

    Danny

    #62432

    jbaudoux
    Participant

    Hello
    I have initiated a PR with support for MQTT.
    https://github.com/OpenSprinkler/OpenSprinkler-Firmware/pull/102
    J-E

    #62650

    dionw
    Participant

    Hi @ray, how close are we to seeing a v2.1.10 or whatever release with MQTT support merged?

    #62681

    Ray
    Keymaster

    I’ve been keeping an eye on the pull request. we won’t be able to integrate this to 2.1.9 as it’s about to be released (finishing up documentations at the moment). But as soon as we are done with 2.1.9 we will start merging the MQTT PR.

Viewing 19 posts - 1 through 19 (of 19 total)

You must be logged in to reply to this topic.