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

  • Loafdude
    replied
    In hs/mcsMQTT the $$NAME:, $$type:, etc variables have their spaces replaced by %20s when published
    When sending spaces in other clients they are still spaces on the other end (including when sending to mcsMQTT)

    Yes I got myself confused. The way you've written it makes sense.

    Leave a comment:


  • Michael McSharry
    replied
    I do not know what you mean by a fix for %20. If I publish a topic that contains %20 from another node then that topic shows up with %20 in the topic in mcsMQTT. What are you doing that is not giving you the expected result?

    It is possible to auto-create a status response for every HS device, but for those who have many devices that would create a lot of undesired traffic and use of system resources. It then gets to be problematic as edits are made to individual associations and then as the default publish template is changed. Would all the existing devices have their status/publish topic changed or would the edit to the default only change the new devices created thereafter. Overall it likely would be confusing.

    Leave a comment:


  • Loafdude
    replied
    I've been deleting the database because the last version was sending me for a loop and it was easier to test consistently with a fresh db. haha

    My fault. I should read the field names more closely.
    I was expecting the Default Topic Template to behave like the subscription wildcard where it would publish everything automatically.

    Apologies Sir!

    Thanks for your hard work on this update and humoring my requests.

    Is %20 fix on your radar or should I workaround it on my end?

    Leave a comment:


  • Michael McSharry
    replied
    Why are you deleting the database? Auto-Associations are only made when a message is received so if you do not see the relationship on the Association tab, then there is no association yet. Could it be that it is just a timing thing between when you deleted and restarted vs when subscription topics have been received?

    Leave a comment:


  • Loafdude
    replied
    Subscriptions seem to work now! (Thanks!)
    Changing the subscription wildcard field does appear enumerate the devices

    But wildcard publishing is now broken?

    I can recreate by this;
    1. Delete contents of Data/mcsMQTT/
    2. Set publish wildcard in general tab
    3. Test devices and check for mqtt messages

    At this point no mqtt messages are sent

    4. Open device on Edit/Add tab with REF number
    5. Change nothing (The publish field is already populated correctly)
    5. Test devices and check for mqtt messages

    Messages are now sent

    Leave a comment:


  • Michael McSharry
    replied
    My mistake. Corrected in 3.4.14.1. http://mcsSprinkers.com/mcsMQTT_3_4_14_1.zip. It should also have the refresh after change of template, but have not confirmed this yet. Dinner time now.

    Leave a comment:


  • Loafdude
    replied
    Yes I can get the output of all these wildcard on the publish side of mcsMQTT
    I use this below to ensure I generate valid data
    PHP Code:
    Publish MaskHome/$$ROOM:/$$TYPE:/$$NAME:/Status
    Publish Result
    Home/Deck/Z-Wave%20Switch%20Multilevel/Deck%20Light%20Dimmer/Status

    Ideal Subscribe Mask
    Home/$$ROOM:/$$TYPE:/$$NAME:($$REF:)/Command 
    I could not get the above subscription to work.
    So I simplified and tried the ones below

    PHP Code:
    Home/Control/$$REF:/Command
    Home
    /Control/101/Command with payload 60
    WORKS

    Home
    /Control/$$NAME:/Command
    Home
    /Control/Deck Light Dimmer/Command with payload 60
    WORKS

    Home
    /Control/$$NAME:/$$REF:/Command
    Home
    /Control/Deck Light Dimmer/101/Command with payload 60
    NOT working 
    I watch the mcsMQTT debug.log to ensure the messages are received. (which they are)
    11/28/2018 3:57:51 PM 3156772 | ActoOnMessageForTrigger Topic Home/Control/Deck Light Dimmer/101/Command,Payload=50


    Could you see if Home/Control/$$NAME:/$$REF:/Command works on your end?

    Leave a comment:


  • Michael McSharry
    replied
    The wildcards are processed during non-plugin device enumeration. This is done at startup and done when the button on bottom of General tab is used. This was done to minimize the time it takes to evaluate each received message. I can see that I should rebuild automatically if wildcard template is changed. I'll do this in next update.

    The topics are case-sensitive so make certain room names obey the case of what is in HS

    $$TYPE: is DeviceTypeString property of the device

    $$ROOM: is Location property of the device

    $$FLOOR is Location2 property of the device

    Use of any substitution in addition to $$REF: is not a good idea because $$REF: is unique and needs no further specification. If you ever get out of sync between name and ref in your example it will not recognize the topic.

    Do any of these help?

    Leave a comment:


  • Loafdude
    replied
    I can get these working
    Home/Control/$$NAME:/Command
    Home/Control/$$REF:/Command

    I can not get these working
    Home/Control/$$TYPE:/$$NAME:/Command
    Home/Control/$$ROOM:/$$NAME:/Command

    **
    Also cannot get this working
    Home/Control/$$NAME:/$$REF:/Command

    Leave a comment:


  • Loafdude
    replied
    Can you explain exactly when the subscriptions are updated.

    For example if I have set inbound wildcard to
    Home/Control/$$REF:/Command
    I send a message to Home/Control/101/Command=60 and it works

    I then change inbound wildcard to
    Home/Control/$$NAME:/Command
    I send a message to Home/Control/Deck Light Dimmer/Command=60 and it does NOT work
    I send a message to Home/Control/101/Command=60 and it works

    I've resorted to deleting the entire database during testing here but it's a bit confusing

    Leave a comment:


  • Loafdude
    replied
    I am using mosquitto as my broker
    My clients are Node-RED and MQTT.fx java app on windows.

    Both clients receive for example
    PHP Code:
    Home/Deck/Z-Wave%20Switch%20Multilevel/Deck%20Light%20Dimmer/Status 
    This is using outbound template
    PHP Code:
    Home/$$ROOM:/$$TYPE:/$$NAME:/Status 
    The Type and Name are actual spaces in homeseer obviously.

    I get the following results from testing
    HS3 -> Node-Red = %20
    HS3 -> MQTT.fx = %20
    MQTT.fx -> Node-Red = Space Character
    Node-Red -> MQTT.fx = Space Character
    MQTT.fx -> mcsMQTT = Space Character (In association tab)

    Leave a comment:


  • Michael McSharry
    replied
    Submitted to Updater and available at http://mcsSprinklers.com/mcsMQTT_3_4_14_0.zip contains the update to allow use any of the Topic substitution parameters in the manual's Table 1.

    I also published a topic with %20 embedded and the %20 was shown on the mcsMQTT association tab for the message. Could it be your observation is based upon your client that may have converted the %20 into space before it sent it to the broker?

    Leave a comment:


  • Michael McSharry
    replied
    I can make the wildcard more generic to include the other appropriate substitution patterns.

    I believe the %20 is being done outside of mcsMQTT. Could be in the M2Mqtt library or by the broker. I will investigate a little.

    Leave a comment:


  • Loafdude
    replied
    Not trying to be a drag...
    Subscriptions would be much more useful for me if there was access to;
    $$ROOM:
    $$TYPE:
    $$NAME:

    It appears only $$REF: works for subscriptions

    Not sure how your accomplishing the subscription
    What do you think about something like

    PHP Code:
    WILDCARD_MASK "Home/$$ROOM:/$$TYPE:/$$NAME:"
    for device in all_devices:
        
    mqtt.subscribe(WILDCARD_MASKdevice

    Leave a comment:


  • Loafdude
    replied
    mcsMQTT is substituting spaces for %20's in MQTT topics for both subscribe and publish.
    Any chance we could change that or have a regex replacement we can run against the topic?

    Backwards incompatible change though

    Leave a comment:

Working...
X