Announcement

Collapse
No announcement yet.

mcsMQTT Plugin

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

  • rgerrans
    replied
    Thanks, the log type does seem to be working better. I'll test that for a few days to see if it works ok on couple of test devices.

    Leave a comment:


  • Michael McSharry
    replied
    First thing t try is on the Edit tab for a Zwave device being used in mcsMQTT and change the Event type from Value Change to Log. This will change the mechanism by which mcsMQTT is informed that HS changed the device. If it works as you desire then change all of your Zwave devices. If not then post the debug file with some info as to the Ref of a device being tested.

    Leave a comment:


  • rgerrans
    replied
    Thanks, I'll try the debug and open up a new thread. All my devices are created by the Zwave plugin if I'm understanding your HS Event reference. I don't use any standalone HS Event triggers

    Leave a comment:


  • Michael McSharry
    replied
    The plugin debug is enabled from the General tab. It produces a file in \Data\mcsMQTT\mcsMQTT Debug.txt. Included in the debug are lines that contain "HSEvent" at the start. This is each callback from HS telling mcsMQTT that a device or log has changed. mcsMQTT will respond to each callback that has been mapped to a MQTT pub topic.

    Before looking at debug you may want to try using the Log HS Event Trigger from the Edit tab for the non-plugin device. HS may deliver only the final state of the dimmer in the log while it may deliver intermediate steps as the dim level value changes.

    Leave a comment:


  • rgerrans
    replied
    Originally posted by Michael McSharry View Post
    Discussion get lost in the main post that is now 27 pages long. Best to create a specific topic.

    What is your source device (i.e. Dimmer) creating the MQTT traffic? Is it a zigbee device? Or is HS the dimmer?

    I do not think MQTT spec requires the broker to deliver traffic in the order that it is received. Are you showing the broker input or broker output in your post?
    Sorry for the delayed response back, understand on the size of thread and will take that path next time.

    It's an HS Dimmer created through the Zwave plugin. I don't have the same issue with the stock MQTT plugin which only delivers the final device state to my MQTT broker. The post above is showing my output from the broker to my Node-Red instance.

    Leave a comment:


  • Michael McSharry
    replied
    Discussion get lost in the main post that is now 27 pages long. Best to create a specific topic.

    What is your source device (i.e. Dimmer) creating the MQTT traffic? Is it a zigbee device? Or is HS the dimmer?

    I do not think MQTT spec requires the broker to deliver traffic in the order that it is received. Are you showing the broker input or broker output in your post?

    Leave a comment:


  • rgerrans
    replied
    Michael - This plugin is making great progress. I just tested it and am seeing an issue that I was looking for some guidance on either what I need to configure differently or if it's a bug/feature of how you designed the plugin. I've noticed on Dimmers that sometimes interim dim levels get reported and sometimes they get reported out of sync. Here is a copy of of what is getting reported to my MQTT server. I turned the dimmer on and immediately turned it off. You can see the off (0%) being reported then a 69% followed by another 0%.

    3/12/2019, 5:30:10 PMnode: a52bbea6.6cfb3home/diningRoom/diningMainLight : msg.payload : string[2] "99"
    3/12/2019, 5:30:14 PMnode: a52bbea6.6cfb3home/diningRoom/diningMainLight : msg.payload : string[1] "0"
    3/12/2019, 5:30:14 PMnode: a52bbea6.6cfb3home/diningRoom/diningMainLight : msg.payload : string[2] "69"
    3/12/2019, 5:30:17 PMnode: a52bbea6.6cfb3home/diningRoom/diningMainLight : msg.payload : string[1] "0"

    Thoughts/suggestions?

    Leave a comment:


  • Michael McSharry
    replied
    I added the capability in 3.5.6.0 which is now at http://mcsSprinklers.com/mcsMQTT_3_5_6_0.zip and I will submit to Updater later in the week. The manual was updated as well. Space to underscore substitution is indicated with suffix of _UNDERSCORE rather than _URI_ENCODE. For example $$ROOM_UNDERSCORE: will take the room location from HS and replace any spaces with underscores.

    If you want to continue this discussion then do in in the Version 3.5 thread or open a new one. It gets buried in a thread that is 27 pages long.

    Leave a comment:


  • paulmona
    replied
    Originally posted by Michael McSharry View Post
    Underscore vs. %20 is not something you can do now. In my case I prefer the underscore and it will be an easy addition.
    GREAT! Killer plugin!

    Leave a comment:


  • Michael McSharry
    replied
    Underscore vs. %20 is not something you can do now. In my case I prefer the underscore and it will be an easy addition.

    Leave a comment:


  • paulmona
    replied
    This plugin works great! Quick question - Is there any way to do an underscore substitution for rooms etc that have a space rather than URL encoding? For example "Paul Room"
    $$ROOM: will evaluate to "Paul Room" or "Paul%20Room" and $$NAME: would evaluate to something like "Main Overhead Light" or "Main%20Overhead%20Light"

    It would be nice, if I could just substitute spaces for underscores rather than URL encoding. Is this doable? I can't figure out how if it is.

    I have a fairly large Z-Wave network now playing nice with Home Assistant and Node Red thanks to this plugin! I plan on leaving all Z-Wave devices in Homeseer because the Z-Wave support is better than anything else I've used.

    Cheers!

    Paul

    Leave a comment:


  • Michael McSharry
    replied
    mcLighting discussion at https://forums.homeseer.com/forum/li...ame-mqtt-topic

    Leave a comment:


  • chuckatwar
    replied
    I just configured a RGB controller running Mclighting. I have it interfaced with HS using your plugin. My question is how do I create multiple devices with the same Subscribe and Publish topic?
    EX:
    Mclighting publishes to KitchenCabinets/out
    McLighting Subscribes to KitchenCabinets/in

    Commands are formatted as such:
    KitchenCabinets/in =off (control of on/off)
    KitchenCabinets/in %50 (Dimmer)
    KitchenCabinets/in #HEXCODE (Color)
    KitchenCabinets/in /45 (animation mode)

    How can I create either different devices for each control? Button style for Control and Animation, color picker for Hexcode and Number range for dimmer.
    Here is the MQTT documentation for McLighting if that helps:
    https://github.com/toblum/McLighting/wiki/MQTT-API


    Thanks!

    Leave a comment:


  • Michael McSharry
    replied
    I can understand #1. The plugin left it up to HS to position the buttons. With next update I will have them presented in numeric order.
    #2 is a HS page. The major UI change between HS2 and HS3 is that generally all edits in HS3 happen immediately and there is no Done button. Some of the jQuery controls do have Done buttons, but not entire pages.
    #3 names are initialized to the Topic of the device so if there are spaces they should be in the received Topic.

    Thanks for the feedback.

    Leave a comment:


  • Steve Q
    replied
    Michael, thanks again for your help. Since I have been working with your plugin a lot during the last few months, I would like to point out a few very minor issues which I think are related to your outstanding plugin.

    1. When HS3 on/off devices are created by the plugin, the ON and OFF buttons are opposite of the default position that HS3 uses. All my other HS3 devices have the OFF button on the left and the ON button on the right. My MQTT devices are the opposite (I have fixed some of them). See photo in post 369.
    2. When HS3 Value devices are created by the plugin, the “status graphics” tab (used to edit the device properties) does not have a “done” button at the bottom of the page. It is not clear how to save any changes made.
    3. When HS3 devices are created that have long names, the plugin puts spaces at odd places in the name. This is a carryover from the mcsxAP plugin.

    Clearly these are minor issues. But I thought I would pass them on to you since you are still updating the plugin periodically.

    Thanks again.

    Leave a comment:

Working...
X