Announcement

Collapse
No announcement yet.

More "user friendly" device creation

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

    More "user friendly" device creation

    Posting on behalf of another user

    I have been using your mcsmqtt plugin to integrate my ESP8266 devices and zigbee devices to my system,

    As I am looking to integrate many more zigbee devices to my environment I am still struggling a bit because of the work it requires to create new devices: associates all mqtt topics to devices, edit the devices to publish topics, open the devices in the device management page to first add floor/room, add button images/state/devices, use jon00 group device to group all device/topics

    Do you have plans to simplify this process in a near future ?

    I understand that this is probably requiring a lot of effort but I am sure I am not the only one that would benefit from this HUGE enhancement

    Thanks for your great work by the way

    p.s. I know HS4 is supposed to bring zigbee but definitely they won't bring anything for any other MQTT driver devices so I would prefer going one way with managing my non z-wave devices and stick with mcsmqtt


    #2
    Currently mcsMQTT tries to be smart about device creation by looking at the previously received payloads to see if it looks like a two-state button, a number or an enumeration and created the VSP and VGP that seems appropriate. If it guesses wrong then the Edit tab is a radio button to select a different type of device. Only if there is some special customization should one need to use HS Device Management.

    It also has a General tab setting to automatically create devices for any newly-discovered topics. This bypasses the step of using the Association tab checkbox. In essence it makes mcsMQTT behave as an opt-out rather than opt-in for MQTT devices on your network.

    Publish topics do not have any automatic action as that depends upon what the other device is expecting. For example, the Zigbee devices expect "set", Tasmota devices expect "cmnd", and Shelly expects "command". Only Shelly has a standard definition for MQTT topics and I will be doing a plugin for customization around these. All others are user-defined.

    Grouping of devices in HS3 is done by Association property of the device. mcsMQTT uses this when the General tab setting is set to have mcsMQTT group devices that share a common Topic. If using Jon00 utility then you will not want mcsMQTT to do it as they will interfere with each other. In HS4 associations are forced by HS4 so I do not think Jon00 utility will work anymore. In HS4 the main topic becomes a device and the JSON items become features of the topic. HS4 uses the association property to manage this so not available to the end-user to group things differently.

    I am open to making the plugin easier to use, but specific suggestions are needed.

    Comment


      #3
      I discovered that I had only non-pluign device auto-association. In 5.0.3.0 I implemented the auto-association based upon wildcard topic template. This means that any topic observed that matches the template will have a HS device created. Furthermore the Outbound (publish) template is used to create the controls for HS so that the device will have controls appropriate for the topic. This means that any topic that matches the wildcard will require no user action. The manual was updated to reflect this capability. Some of the excepts are shown below.

      5.0.3.0 is available at http://mcsSprinklers.com/mcsMQTT_5_0_3_0.zip. Update were also made to the HS4 mcsMQTT plugin, but I have not yet published it for general use.
      1.1Automatic Setup of Device to Topic Relationship

      The default operation of mcsMQTT is to firewall all MQTT Topics and allow the user to selectively associate each with a HS device. This is the “opt-in” approach. The Association tab shows all the Topics that have been detected.
      This default operation can be changed where the Association tab firewall becomes an “opt-out” or hybrid of “opt-in” and “opt-out”. The General tab, Incomming (Subscription) Management section has a line for “Wildcard Plugin Auto Associate Template”. When this text box is left blank the default “opt-in” behavior will be used. When one or more Topic templates are entered then the Topics that match the template with have HS device automatically created. Other topics will be firewalled at the Association tab for user selection. The Topic template follows MQTT topic wildcard standards where “+” designates current position in hierarchy and “#” is used to indicate everyting at this and postions to the right. To Auto-Associate everything the template would simply by “#”.
      1.1.1How do I automatically create HS devices based upon MQTT Topics

      mcsMQTT will collect all topics for viewing in the Association tab and the user is able to create HS devices by using the “A”ssociate checkbox. This opt-in selection can be changed into an opt-out selection by using plug-inTopic wildcard template for the Topics that will automatically have HS devices created. This template is found on the Inboud Management section of the General tab. If every topic is to create an HS device then the template is “#”. If it is to create HS devices for all topics with “RESULT” in the second position then the template would be “+/RESULT/#”. The template uses standard MQTT Topic wildcarding. Anything that does match the wildcard template will obey the opt-in rules. Devices that were auto-created and are not desired can be removed with “A”ssociate textbox on the Association tab. Auto-Association only applies to the initial detection of a topic.
      When Auto-Association is used then it may be useful to also set the Topic Template in the Outbound Management section of the General Tab. When this template is not blank then any HS device that is created will have a publish Topic setup and either Buttons or Number text boxes setup with the HS device. For example, Shelly devices suffix the Topic with “/command” to indicate that the topic is commanding the Shelly device. The Topic template in this case would be “$$Topic:/command”. Tasmota devices use “/cmnd” placed either as a prefix or before the last segment of the Topic. If the substitution is “$$TASMOTACMND:” then mcsMQTT will evaluate the Topic and put the “/cmnd” in the proper position. For example “Switch/Power” becomes “Switch/cmnd/Power”.
      If there are multiple sets of Topics that are whitelisted then each should be separated by semicolon. This then servers as an OR function to Auto-Associate different sets of Topics, but not all topics. Figure 2 shows an example of topics starting with “Test/” and those with “STATUS” in the second position will have HS devices created whenever mcsMQTT detects these topics.



      Comment


        #4
        Michael

        I definitly prefer the Opt-in options wich fills much better my needs and prevents the creation of probably many "ghost devices" that would get lost in my few thousand devices. what I suggest is to have a way when we are in the Association tab and manually select a device and click on it's ref number to be able to edit directly in the windows that opens the floor/room fields and the status graphics That would simplify the process where we could immediatly complete the information for the created device insteak of going back and forth to the device management. Unless I am missing something I have found no way of doing it directly from the association table.

        Comment


          #5
          There currently is the ability to edit the Value/Status pairs. The graphics icons default to on.gif, off.gif and dim.gif and no ability to edit. The floor and room are derived from the topic and no ability to edit. How often do you change the graphics? The floor and room edit is easy to add and could also provide option to default to static values of each in lieu of values derived from the topic.

          Comment


            #6
            Originally posted by Michael McSharry View Post
            There currently is the ability to edit the Value/Status pairs. The graphics icons default to on.gif, off.gif and dim.gif and no ability to edit. The floor and room are derived from the topic and no ability to edit. How often do you change the graphics? The floor and room edit is easy to add and could also provide option to default to static values of each in lieu of values derived from the topic.
            I am not changing the graphics (or almost never) once a device is created unless I need to reset or recreate the device but at every creation of a device I do apply my own icons. Best example I could mention is I just added 4 Xiaomi humidity sensor where every device creates 5 topics. This evidently implies that I had to go in 15 devices to perform the task.

            Most people will say this is not the end of the world, an hour and it's done but since I am thinking of starting back to scratch when HS4 will be out this probably means over 300 devices created by mcsMQTT associations to modify including my zigbee, ESP, weather devices...

            Anyway this is a nice to have feature and will continue this way if there is no changes but long term I think this could be a benifit to be able to modify any aspect of the device from the same place.
            Attached Files

            Comment


              #7
              I am adding the Location default option to the General tab and ability to edit on a device by device basis in the Edit tab. I likely can also add the graphic as part of the exist VSP edit capabilty. I will take a look at this.

              Comment


                #8
                Originally posted by Michael McSharry View Post
                I am adding the Location default option to the General tab and ability to edit on a device by device basis in the Edit tab. I likely can also add the graphic as part of the exist VSP edit capabilty. I will take a look at this.
                Great Thanks Michael

                Comment


                  #9
                  I am uploading version 5.0.4.0 now. http://mcsSprinklers.com/mcsMQTT_5_0_4_0.zip. I did not do anything with the graphics. General Tab Inbound section has setting for operation of setting Floor and Room at device creation. Edit tab has ability to edit these properties.

                  Comment


                    #10
                    So I am guessing my confusion has been my process of connecting a HomeSeer device with an MQTT topic. I have created a virtual device and then felt like I struggled associating it with a received topic. I admittedly have been overwhelmed with the documentation so my first attempt was to just do it and then figure out how. It was not intuitive. I appreciate all the effort in the coding and especially documention and could probably ignore parts of the document but the feeling is that I shouldn't.

                    I was excited to see this thread and frankly I have been trying to think of how to make the plugin more intuitive/friendly but am not sure I have anything good. Best I have is: What about some sort of Wizard? Maybe a series of screens to prompt the end user through the steps.
                    1. In the Config have a New Device/Topic button. Select it and get a prompt to
                      1. Connect an unconnected topic to an existing device
                      2. Create a new device for an unconnected topic
                      3. Other
                    2. Next, prompt for the Topic and payload(s)
                    3. Prompt for the device it information to create the device
                    This is a basic outline. You know the product better than I and I'm sure could flesh it out more. Or make it a series of wizards to do different things. I also know it would be a chunk of work but I'm wondering if it would help limit questions. Basically work at the front end to offset the long-term effort. Still keep the advanced view. I just know that a casual user probably had to look up stuff like what the single character columns (A for instance) mean each time they go to do something in the plugin. I know I am forgetful on these until I have some it enough, which hasn't happened yet.

                    Another option might be to put the documentation online someplace as a series of web pages. It might not feel as daunting if it is a series of smaller pages which are more paperless friendly. I feel like I need to print the entire current document but then lose the up to date reference. I think it would be ideal if we could get the folks at HomeSeer to do some sort of wiki site, but it would need to be opened to allow the community to edit. No need to go on about that, there are old threads on the idea already. Bottom line, some of us would contribute so there would be more content available and then the plugins could have centralized documentation as well as being to subscribe to a notification of a change. And this is coming from a slightly older generation person where the desire is normally to have paper instructions at hand.

                    Again, I appreciate all the effort in all you plugins. Keep up the good work!!!

                    Kindest Regards,
                    Karl S
                    Karl S
                    HS4Pro on Windows 10
                    1070 Devices
                    56 Z-Wave Nodes
                    104 Events
                    HSTouch Clients: 3 Android, 1 iOS
                    Google Home: 3 Mini units, 1 Pair Audios, 2 Displays

                    Comment


                      #11
                      I am always open to being responsive to user needs and desires. I did an interview sequence in mcsSprinklers to guide the user through setting up their irrigation scheduling. mcsSprinklers has many options and the guided process was something that kept it from being overwhelming to know which option to use. This worked because the end objective was an irrigation schedule.

                      With mcsMQTT it is a different ballgame because there are a very wide variety of use cases. There is not single end objective for with a step by step guidance could be given. The manual is intended to be primarily a reference and not a tutorial. It does, however, contain Section 4 which is the quick start. It includes some very basic use cases and some more advanced. Today there are 31 of these uses cases that show how each is accomplished with the mcsMQTT setup.

                      Different users are at different levels of understanding with interfacing IOT devices. Some are at square one and need guidance on setting up a network. Others have an environment setup that is using MQTT protocol and are HS novices. When trying to help the community overall the manual becomes large and its size just overwhelms as you indicated. Adding more to it will only make the matter worse. There would need to be another place where more bite-size pieces of information could be located. The message board has some of this. It also, however, is not a guided tutorial, but a case by case study of use of mcsMQTT.

                      For context sensitive information, such as the A column checkboxes there are mouse-over tool tips that show over every user input. Again the value of the tool tip depends upon the level of the user and what understanding they already have. If one does not understand MQTT topics and payloads then the Association of these with HS devices will hard to understand. I am open to updating the mouse-over popups on a case by case basis if specific text is volunteered that would make the feedback more appropriate.

                      As a note, Section 14 of the manual contains the full set of tool tip text. Reading these in paragraph format may not be intuitive and actually may be a step backward from seeing them in context with the mouse-over. Again, not a tutorial, but a reference.

                      This thread started based upon a user desire to put additional editing capability in mcsMQTT so there would not be the need to go back and forth between HS and mcsMQTT. I misunderstood the request and initially added a greater degree of device creation automation. While there are some uses that may benefit, it was not what this user desired so tried again.

                      Like I indicated at the start I am open to any suggestion, requests or community contribution to make use of MQTT with HS easier. There have been some user that have posted how-to's and these are helpful. Some were reposted on the first post in the main mcsMQTT sticky thread.

                      Comment


                        #12
                        Originally posted by Michael McSharry View Post
                        I am uploading version 5.0.4.0 now. http://mcsSprinklers.com/mcsMQTT_5_0_4_0.zip. I did not do anything with the graphics. General Tab Inbound section has setting for operation of setting Floor and Room at device creation. Edit tab has ability to edit these properties.
                        Hi Michael just got a chance to install nd test the 5.0.0.4 version, that is great if I may, do you have anyway to have the drop down menu so we can select the location from the list already existing in the system... Sorry for asking but otherwise this will definitly help with new device creation

                        Comment


                          #13
                          +1 on the above (drop down menu for "floor/room") if feasible ,

                          Thx Michael / Goldriver

                          Comment


                            #14
                            Changed in http://mcsSprinklers.com/mcsMQTT_5_0_4_2.zip from text box to drop down selector. The implication is that the room and floor must already exists. If a new one is created then either restart the plugin or use the enumerate button at the bottom of the General tab. Enumeration of all HS devices is an expensive resource activity so only want to do it when necessary.

                            Comment


                              #15
                              Did not had chance until this morning to fully test the drop down for locations, it turns out there is a little issue with retaining the floor selection.

                              I added a Xiaomi water detector from zigbe2mqtt topics this morning, this created 4 topics to wich I clicked the "A" association button and without leaving the mcsmqtt config, I once by once went in each of the 4 devices (clicking on the Ref number) and changes the floor/room assignment by selecting in the drop down. Once done for all 4 devices, I quit mcsmqtt configuiration page and went in the devive management page and filtered on the room/floor and only 2 of the devices appear.

                              I went back in mcsmqtt configuration, looked in the missing 2 devices and both did not retain the floor. I changed both of them floor, went back in device management now there were 3 out of the 4 devices, once again went in mcsmqtt configuration and changed the last device .

                              The problem does not seem to be consistant because I added another water sensor and this time only one of the devices floor was not keept.

                              Comment

                              Working...
                              X