Announcement

Collapse
No announcement yet.

Wildcard Template for Auto-Association of MQTT control topics to existing HS devices

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wildcard Template for Auto-Association of MQTT control topics to existing HS devices

    Introduced in 3.4.13.0 of mcsMQTT is a time-saving feature for those who have the ability to publish standard topic formats to control HS devices. The topic will include the HS Device Reference. When the wildcard template is setup (General Tab, Incoming Subscription Management) mcsMQTT will match it with existing HS device and make an automatic acceptance. Default publish and payload templates will be associated so when the device changes it will be reported via MQTT. Once setup it is possible to edit any of the properties on a Device by Device basis. The manual was updated to reflect a use-case example and as a method to assign Topics to existing HS devices.

  • cytec
    replied
    I ended up making a custom solution using the HTTP JSON interface, posted to Github:

    "homeseer2mqtt"

    https://github.com/ben423423n32j14e/homeseer2mqtt

    Leave a comment:


  • Michael McSharry
    replied
    The concept is to allow the user to edit device associations individually so once the association is made it will only change on a device by device basis even if the default templates are changed. If you want the payload template to be different for everything then a safe way to do it is to delete \data\mcsMQTT\mcsMQTT.db and then start the plugin so it will create everything with new defaults.

    Leave a comment:


  • cytec
    replied
    @Michael McSharry

    "Associate all non-plugin HS Devices immediately" is working.

    One small change needed which is to force the "Default Payload Template" upon all Associations. Currently this only occurs once, not if the user updates it.

    Eg if the user changes the "Default Payload Template" on the General tab, it is not currently applied to all the associations.

    A work around is to toggle between these tick boxes in the GUI.

    "Associate Topic to HS Device upon receipt of control Topic"
    "Associate all non-plugin HS Devices immediately"

    Btw this works really well for sending a JSON formatted payload:

    { "ref": $$REF:, "name": "$$NAME:", "value": "$$VALUE:", "type": "$$TYPE:" }

    mcsMQTT General Tab:
    Click image for larger version  Name:	345345345.JPG Views:	1 Size:	24.2 KB ID:	1263433

    How it looks in Node-Red:

    Click image for larger version  Name:	node-red-json-hs.JPG Views:	1 Size:	26.4 KB ID:	1263434

    Sample Node-Red flow if anyone finds it useful

    [{"id":"fdb6cc25.a5c32","type":"function","z":"a92a988d.6d afa 8","name":"Logic","func":"// Variables\nvar test = JSON.parse(msg.payload);\nmsg.payload = {}\nmsg.payload = test;\nreturn msg;\n","outputs":1,"noerr":0,"x":930,"y":220,"wires":[["effae800.48baa8"]]},{"id":"5aea4253.881adc","type":"mqtt in","z":"a92a988d.6dafa8","name":"","topic":"homeseer/#","qos":"2","broker":"3437cea9.b22eb2","x":760,"y":220," wir es":[["fdb6cc25.a5c32"]]},{"id":"effae800.48baa8","type":"debug","z":"a92a988d.6daf a 8","name":"","active":true,"tosidebar":true,"console":fal se, "tostatus":false,"complete":"payload","x":1090,"y":220," wire s":[]},{"id":"3437cea9.b22eb2","type":"mqtt-broker","z":"","name":"MQTT","broker":"homeseer.local","port ":"1883","clientid":"","usetls":false,"compatmode":true, "kee palive":"60","cleansession":true,"birthTopic":"","birthQos": "0","birthPayload":"","closeTopic":"","closeQos":"0","cl oseP ayload":"","willTopic":"","willQos":"0","willPayload":""}]

    Connects to MQTT, Parse's the JSON and prints the output to debug

    Leave a comment:


  • cytec
    replied
    @Michael McSharry

    Thanks I will move the sensor updates component to using mcsMQTT (you are correct, MQTT is ultimately better for near real-time updates), if it's available I will use it to avoid the 100ms json poll.

    I've got the entire JSON on a seperate 30 second interval going into a local array in Node-Red so can match up data from the mcsMQTT via the ref and pull richer data from the JSON (eg if there is a battery level) or associations.

    Should be a fun night of coding,

    Leave a comment:


  • Michael McSharry
    replied
    I did add the option to either create upon reception or as you desire to create immediately to http://mcsSprinklers/mcsMQTT_3_4_16_0.zip. You can interface the two however you like. Pulling works fine for small population of devices. For those that have 100's or 1000's the latency can become excessive in not only with the data being pulled, but also due to the resource consumption that delays everything down. Over time HS has tended to change their API so it is something you need watch over and continue to maintain the interface.

    Leave a comment:


  • cytec
    replied
    @Michael McSharry
    I've built 90% of the solution now using Domoticz MQTT and HomeSeer JSON interface (not using mcsMQTT).

    Interestingly I can pull the entire HomeSeer device list via JSON using curl in just "0m0.059s", that's just 59 milliseconds to get the status of my 30 or so Z-Wave devices.

    Also it's using a very small amount of system CPU < 3% calling it every 100ms, I've decided to continue building the interface upon the concept of requesting the entire device list non-stop from HomeSeer via JSON.

    It sounds like waste of resources, but I can turn a light on in Domoticz and it is so fast I cannot see any distinguishable delay between previously using OpenZ-Wave directly with Domoticz or this new concept of off-loading Z-Wave to HomeSeer.

    Devices reported via HomeSeer JSON are up to date RE their status, even the motion sensors are working wonderfully again with no distinguishable delay.

    I'm surprised but the HomeSeer JSON interface is looking like the best way to go forward, in particular it provides very rich information I can use to further enhance the solution. Eg search for child devices containing a battery value and automatically attach it to the Domoticz device.

    Cheers

    Leave a comment:


  • Michael McSharry
    replied
    For office, what is the actual Hs device name property for the root device? While HS provides a display of office root it does not mean the name is “office root”, but likely is “office” and Hs appends “root” in the display to distinguish it from the child. Take a look and let me know. Note also the association tab will show the associations that have been automatically added.

    Domoticz looks to be designed as if it is king. I see much special logic in the Tasmota source so it can be configured to comply with Domoticz conventions. McsMQTT makes no assumptions about conventions used by other MQTT nodes with the intent of being able to bring any MQTT node into the HS world.

    Most HS users will have a small percentage of their devices as being MQTT cognizant. Having everything publish will consume system resources and add no value for most users. I could add option for auto accept of non-plugin devices, but I can foresee confusion and difficulty when one desired to change the templates after associations already exist.

    Leave a comment:


  • cytec
    replied
    Found another problem, if the tick box in this screenshot is ticked, I get status updates via MQTT, if it's not then no status updates occur.

    Isn't it supposed to be automatic for all devices?

    Click image for larger version  Name:	screen554.JPG Views:	1 Size:	82.6 KB ID:	1263151

    MQTT output received via Node-Red (when the checkbox above is ticked).

    Click image for larger version  Name:	output545.JPG Views:	1 Size:	38.5 KB ID:	1263152

    For this application, I wonder if it would be better if the plugin was massively simplified, eg remove tabs:

    Associations, Edit/Add, Pub List, Statistics, History, Chart

    There really isn't even need for defining the wildcards, it could just be hard coded into the plugin.

    User only needs to enter their MQTT server settings?

    In Domoticz MQTT implementation, this is all the user needs to fill out, everything else is fully automatic.

    We can control any Domoticz device via MQTT topic domoticz/in

    Anytime a device status changes, it is automatically published to MQTT topic domoticz/out

    Click image for larger version  Name:	domoticzmqtt2.JPG Views:	1 Size:	61.8 KB ID:	1263160

    Leave a comment:


  • cytec
    replied
    @Michael McSharry

    Found a bug in the implementation, see attached screenshot.

    If attempting to control "/homeseer/Control/Office/Command" and the top device is named "Office Root", mcsMQTT attempts to control "Office Root" instead of "Office".

    There is somewhere a problem with the $$NAME: code, $$REF: works fine (obviously my application depends on ultimately using the $$NAME.
    Attached Files

    Leave a comment:


  • cytec
    replied
    @Michael McSharry

    I actually use Domoticz as the core of my home automation system, everything feeds back into it either via Node-Red or the JSON interface.

    I agree with your suggestion, RE using names over the ref ID.

    My full project is to create a seemless interface between HomeSeer and Domoticz (via Node-Red).

    I've already succeeded in automatically:

    * If a Domoticz virtual device is switched on or off, see if there is an identical named device in HomeSeer and set it to the same (using Node-Red and mcsMQTT).

    Click image for larger version  Name:	flow775.JPG Views:	1 Size:	24.8 KB ID:	1263146

    Goal is to have devices (switches, motion sensors, door sensors etc...) all automatically match up between Domoticz and HomeSeer if they are named the same.

    Also I can't see any noticeable delay in controlling a Z-Wave device via Domoticz > MQTT > Node-Red > HomeSeer which is fantastic!

    This way I can use HomeSeer for it's fantastic certified Z-Wave support but have all the flexibility of Domoticz.

    I guess ultimately it's personal preference, but after 4 years of using OpenZWave, suffice to say I am not a fan of it.

    I'll post a Github link once I've finished the interface.

    Leave a comment:


  • Michael McSharry
    replied
    I have never started to use node-red so the flow does not mean much to me. What I get from it is that the topic is "/homeseer/Control/105/Command" and the payload in "On". I think you are indicating that it is working for you.

    As a long term consideration you may want to use human names for identification (e.g. Room & Name) rather than computer names (Device Ref). If for some reason the device at 105 needs to be recreated then you will never again get it to be 105, but will be the next available number assigned by HS3. You can control the Room, Floor, and Name. $$ROOM:, $$FLOOR:, and $$NAME: are the substitution patterns for these in mcsMQTT. Table 1 of the manual will give you the set of available substitution patterns.

    Leave a comment:


  • cytec
    replied
    This Node-Red flow works for on / off control of a HomeSeer device via REF

    [{"id":"61ef33df.d4748c","type":"mqtt out","z":"a92a988d.6dafa8","name":"","topic":"/homeseer/Control/105/Command","qos":"","retain":"","broker":"5e06ebd0.e4e9d4","x" :780,"y":500,"wires":[]},{"id":"ad3232e6.9bf6b","type":"inject","z":"a92a988d.6dafa 8","name":"","topic":"","payload":"On","payloadType":"str"," repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":570 ,"y":500,"wires":[["61ef33df.d4748c"]]},{"id":"5e06ebd0.e4e9d4","type":"mqtt-broker","z":"","name":"MQTT","broker":"192.168.0.5","port":" 1883","clientid":"","usetls":false,"compatmode":true,"keepal ive":"60","cleansession":true,"birthTopic":"","birthQos":"0" ,"birthPayload":"","closeTopic":"","closeQos":"0","closePayl oad":"","willTopic":"","willQos":"0","willPayload":""}]

    I entered this into mcsMQTT plugin > General tab "Wildcard Non-Plugin Control Template" which is under the "Inbound (Subscription) Management" section:

    /homeseer/Control/$$REF:/Command

    Leave a comment:


  • Michael McSharry
    replied
    It was an easy addition with option on the General Tab / Outgoing messages. I am actually surprised the subject never came up before since a space is a common character in locations and names. http://mcsSprinklers.com/mcsMQTT_3_4_15_0.zip

    Leave a comment:


  • Loafdude
    replied
    Good point.
    I'll just handle it on the other end. Don't bother implementing for me.

    Leave a comment:

Working...
X