Announcement

Collapse
No announcement yet.

mcsMQTT Plugin

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • drodegeb
    replied
    Originally posted by Michael McSharry View Post
    From Device Management where all HS3 devices are listed you will see the Status of the device. Note I have last row with STATE:Uptime showing with "Minutes" suffix formatting. Clicking on the STATE:Uptime hyperlink brings up three tabs and the Status Graphics is shown. For this example I used "Minutes" for the suffix, Include Values for the checkbox and specified on decimal places. I also put a Value range, but dont know if that is needed or not.
    That is perfect! I wasn't adding a range, so I didn't see the prefix/suffix, working great now!!

    Thanks.

    Leave a comment:


  • Michael McSharry
    replied
    Looks like I fat-fingered the HSevent code. Fixed in 3.0.1.1 http://mcsSprinklers.com/mcsMQTT_3_0_1_1.zip to properly handle the event callback.

    Leave a comment:


  • Michael McSharry
    replied
    [qutoe]Another thing I'm noticing tonight. When I set it up to link an existing device to mqtt (selecting A for an existing device) and control the device by turning it on and off, I never see those changes being sent. If I wait a while, apparently the 10 minute timer, the current status at the time is getting sent.[/quote]

    That should not be the case as the main purpose is to reflect the changes in devices as new messages in MQTT. mcsMQTT looks for all VALUE and STRING changes as part of the HSEvent callback from HS3.

    I will reconfirm on my side, but it may be helpful to understand the nature of the device that you are using. Can you show the Advanced Tab for the device when it is ON and when it is OFF (or whatever states). I am interested in the Value and String properties.

    Leave a comment:


  • Michael McSharry
    replied
    How do you do the suffix part? I've been searching through the device config pages, and the plugin and can't find it. I have temperature and humidify values that are coming up as "DIM xx%", for the temperature one I would like to remove DIM and % and add F, for humidity I would like to get rid of the DIM.
    From Device Management where all HS3 devices are listed you will see the Status of the device. Note I have last row with STATE:Uptime showing with "Minutes" suffix formatting. Clicking on the STATE:Uptime hyperlink brings up three tabs and the Status Graphics is shown. For this example I used "Minutes" for the suffix, Include Values for the checkbox and specified on decimal places. I also put a Value range, but dont know if that is needed or not.
    Attached Files

    Leave a comment:


  • petez69
    replied
    Originally posted by Michael McSharry View Post
    I made the updates discussed.
    Michael

    Stunning.....works exactly as you advised.

    After more tinkering I've simplified my setup even furthur thanks to your work. There is a whole lot more I could write but I'll leave it for now.

    Just did more event testing on incoming payload using a WEMOS to trigger an output on SONOFF Basic, awesome

    Cheers..Pete

    p.s your code is adhering to the API and I'm now getting "ping" updates from the broker via a cronjob :-)

    Leave a comment:


  • drodegeb
    replied
    Another thing I'm noticing tonight. When I set it up to link an existing device to mqtt (selecting A for an existing device) and control the device by turning it on and off, I never see those changes being sent. If I wait a while, apparently the 10 minute timer, the current status at the time is getting sent.

    Thoughts?

    Leave a comment:


  • drodegeb
    replied
    This plugin is great!

    How do you do the suffix part? I've been searching through the device config pages, and the plugin and can't find it. I have temperature and humidify values that are coming up as "DIM xx%", for the temperature one I would like to remove DIM and % and add F, for humidity I would like to get rid of the DIM.

    Thanks

    Originally posted by Michael McSharry View Post
    For other non-numeric payloads the DeviceString will be updated and the Status will show up as the DeviceString. For all others the DeviceString will be cleared. Device Management of Devices can be used to provide suffix, prefix and some other formatting information for Status. For example, a number is treated by default as a Dim level. I change mine to add a suffix (e.g. Minutes) to provide a meaning to the number and remove the Dim prefix.

    Leave a comment:


  • Michael McSharry
    replied
    I made the updates discussed. I do not see the plugin in the updater yet. I have not updated the manual yet either. You can get it at http://mcsSprinklers.com/mcsMQTT_3_0_1_0.zip

    If you have a message received that has case-insensitive OPEN, CLOSED, ON, or OFF as the Payload when the Topic is accepted then the created device will create Device-Value-Graphic pairs and handle OPEN/ON as DeviceValue=1 and CLOSED/OFF as DeviceValue=0. In this case the DeviceString will not be updated and the Status shown will be from the Device-Value-Graphic that is setup. If you want different text or icons then they can be edited. If it not a number and not one of these four then the DeviceValue will not be updated. In the future I think I will expand this to map every text string received on a topic to a unique DeviceValue so they will be treated as an enumeration and DeviceValue changes can be used in events to achieve desired trigger results.

    For other non-numeric payloads the DeviceString will be updated and the Status will show up as the DeviceString. For all others the DeviceString will be cleared. Device Management of Devices can be used to provide suffix, prefix and some other formatting information for Status. For example, a number is treated by default as a Dim level. I change mine to add a suffix (e.g. Minutes) to provide a meaning to the number and remove the Dim prefix.

    DeviceLastChange is now explicitly updated based upon the device's checkbox. It will either update the date on a value change or upon new topic reception based upon the checkbox.

    MQTT Receive trigger how has provisions for the Payload. It likely means that you will need to redefine existing MQTT Receive Trigger Events.
    Last edited by Michael McSharry; December 20, 2017, 11:17 PM.

    Leave a comment:


  • petez69
    replied
    Originally posted by Michael McSharry View Post
    What is the payload on the Topic /stat/wemos-sonoff/POWER?

    If it is OFF/ON then the DeviceValue should never change from 0 and the DeviceString will contain the payload.


    There are two things I have been considering. One is the case where non-numeric payloads are received. In this case then look up to see if a status pair has been defined by the user and then store the numeric value if it matches.

    The other is to expand the MQTT trigger to include the payload. This would allow trigger on a message reception based upon a payload for a topic rather than just a topic. This would allow two events to be setup where one is for an ON payload and the other for an OFF payload, as an example.
    Michael

    OK, payload is ON or OFF, that's what the tasmota firmware sends, hence this is why devicevalue never changes. Understand I could use another plugin but I'd prefer not to as it would then require additional configuration for a single device to enable triggers to occur.

    So to expand the trigger on payload, that is something you would need to code ? I did read your documentation and I see you can trigger on topic but not payload. Is this something you could consider as it would make the triggering of events very simple if we could define the payload and not just the topic. This will make using your plugin with the sonoff tasmota firmware a total breeze to use.

    And thankyou for considering the change in code to honour the API. Again this means I can run a cronjob on the broker and track the "keepalive". I did note you have a trigger option if it doesnt get a message in a self determined timeframe.

    Cheers & regards..Pete

    Leave a comment:


  • Michael McSharry
    replied
    I'm a little stumped as to how to trigger an event from a received MQTT topic. Actually its probably not a topic, its a device I've created as a result of /stat/wemos-sonoff/POWER

    The device on the web page turns on and off fine as I ground the wemos PIN. What I cant seem to work out is how to trigger an event from this.

    What device value is on/off or do I need to define this myself ?

    I've gone into status graphics and set 0 to off and 1 to on....I cant seem to trigger an event from on or off/0 or 1 device status and value....

    Clearly missing something simple....

    Appreciate your guidance
    What is the payload on the Topic /stat/wemos-sonoff/POWER?

    If it is 0/1 then the DeviceValue will change between these two values. If you have status-graphics pairs setup for 0 and 1 values then the Status should show whatever graphics you setup for these two states.

    If it is OFF/ON then the DeviceValue should never change from 0 and the DeviceString will contain the payload.

    HS Events will support a change in DeviceValue. There are 3rd party plugins that will do DeviceString as the trigger.

    There are two things I have been considering. One is the case where non-numeric payloads are received. In this case then look up to see if a status pair has been defined by the user and then store the numeric value if it matches.

    The other is to expand the MQTT trigger to include the payload. This would allow trigger on a message reception based upon a payload for a topic rather than just a topic. This would allow two events to be setup where one is for an ON payload and the other for an OFF payload, as an example.

    I've created a device from stat/mqtt/alive

    Seem to have an issue with the device adhering to the checkbox being turned off:

    Do not update device last change time
    if device value does not change:

    I've turned this off and sent the following:

    mosquitto_pub -d -t stat/mqtt/alive -m ping

    If I send it in a minutes time, the timestamp on the web page doesnt change. If I change the payload then it updates the data on the web page fine. I was going to run a crontab on the raspberrypi every 5 mins so I can keep tab of the device being alive. I know you have another way to do it which is fine but curious as to why this is happening ?

    Any ideas ?
    I was not aware of HS3 providing the setting to control the device last change being used for device last refreshed. I will research the API and honor it in the next plugin update.

    Leave a comment:


  • petez69
    replied
    Michael

    I've created a device from stat/mqtt/alive

    Seem to have an issue with the device adhering to the checkbox being turned off:

    Do not update device last change time
    if device value does not change:

    I've turned this off and sent the following:

    mosquitto_pub -d -t stat/mqtt/alive -m ping

    If I send it in a minutes time, the timestamp on the web page doesnt change. If I change the payload then it updates the data on the web page fine. I was going to run a crontab on the raspberrypi every 5 mins so I can keep tab of the device being alive. I know you have another way to do it which is fine but curious as to why this is happening ?

    Any ideas ?

    Thanks Pete

    Leave a comment:


  • petez69
    replied
    Michael

    I'm a little stumped as to how to trigger an event from a received MQTT topic. Actually its probably not a topic, its a device I've created as a result of /stat/wemos-sonoff/POWER

    The device on the web page turns on and off fine as I ground the wemos PIN. What I cant seem to work out is how to trigger an event from this.

    What device value is on/off or do I need to define this myself ?

    I've gone into status graphics and set 0 to off and 1 to on....I cant seem to trigger an event from on or off/0 or 1 device status and value....

    Clearly missing something simple....

    Appreciate your guidance

    Pete

    Leave a comment:


  • petez69
    replied
    Michael

    Thanks mate, this is a ripper of a plugin. Took me a little time to understand your config page but I've got it happily driving a Tasmota/Sonoff basic relay. Setup a virtual device with a back end script to turn the device on and off, thats now also working with Alexa....

    Great work mate, very happy

    Pete

    Leave a comment:


  • Michael McSharry
    replied
    I compiled/uploaded a third time to connect to localhost rather than .194.

    Leave a comment:


  • vasrc
    replied
    Originally posted by snowboarder View Post
    When i start in Homeseer in Developer Mode i see that the plugin want to connect to server ip 192.168.0.194 . this is not the ip of my homeseer server.
    Download the zip file again. He's fixed that in the latest one.

    Z

    Leave a comment:

Working...
X