Announcement

Collapse
No announcement yet.

Is there a way to combine two physical devices into 1 virtual device?

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

    Is there a way to combine two physical devices into 1 virtual device?

    I have two shelly1 devices contained in the same enclosure. Each with 1 set of controls. I would like to display them on the main device screen as 1 device but with 2 sets of controls, one control for each shelly.

    Is that possible?

    #2
    Absolutely possible, take a look at Jon's utility for doing this:
    Jon00 Device Grouping Utility (web page) for Homeseer 3 & Homeseer 4 - HomeSeer Message Board

    Comment


      #3
      Originally posted by TC1 View Post
      Absolutely possible, take a look at Jon's utility for doing this:
      Jon00 Device Grouping Utility (web page) for Homeseer 3 & Homeseer 4 - HomeSeer Message Board
      This may work, however some plugins will repair broken groupings after you set them with Jon’s utility. In my experience, changing grouping on plugin owned devices, rarely holds.

      HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

      Comment


        #4
        Originally posted by randy View Post
        This may work, however some plugins will repair broken groupings after you set them with Jon’s utility. In my experience, changing grouping on plugin owned devices, rarely holds.
        Good point, I had not thought about that.

        dmagerl another thing you could do is create a new Virtual Device that has a child feature for each of your shelly devices, and then use HS's Device linking feature. Operating the virtual device children would then operate the individual shelly devices.

        Comment


          #5
          What I suggest is that you post your question in a thread in the AK Shelly, mcsMQTT, mcsShelly or whatever forum appropriate for the plugin that you are using for Shelly integration. I know I will be able to accommodate whatever you desire if you are using one of my plugins.

          Comment


            #6
            FYI, here's what I'm trying to do.

            I'm homebrewing a couple tabletop controllers. I've made two types. The unit on the left using a single shelly i4 module. The disassembled unit on the right has 2 shelly2.5 modules. I prefer the unit on the right because it controls the illuminated switches for some user feedback as to which buttons are "on".
            Click image for larger version  Name:	image.png Views:	0 Size:	321.3 KB ID:	1655475

            In Homeseer, The i4 version shows up like this. There are no relays in it so it shows as buttons only.
            Click image for larger version  Name:	image.png Views:	0 Size:	34.3 KB ID:	1655476

            The 2 shelly version shows up as this. Without renaming the devices, the two modules dont even show on the same line.
            Click image for larger version  Name:	image.png Views:	0 Size:	86.6 KB ID:	1655478

            So, assuming I just didnt know how to do it, I was asking if it was possible to combine them into one device. From all the responses, it appears that its not possible so I'll just go on using it like it is.

            Michael, thanks for your offer to help, they use MQTT, but I'm not sure its worth the effort to go any further.

            Thanks everyone!​​​​

            Comment


              #7
              There are two general approaches available. What was described about using Jon00 tool or using mcsMQTT Edit tab is to move a Feature from one Device to another. This is the Grouping Ref on the mcsMQTT Edit tab. This approach will not change the number of Features, but just where they are grouped.

              In your case I believe you have all four of your Features grouped under the same HS Device. The issue is how HS allocates rendering space for the Tiles. If you were using the List rather than Tile view then there would not be an issue as each row in the list will show the corresponding control.

              The other approach is to have a single control Feature that contains all the buttons while at the same time the individual status of each is still visible on the Tile's top row. It appears that HS will extend the vertical space of a Tile to handle all the buttons of a single Feature.


              The VSP definitions are now:
              If Shelly sends "false", then store in HS Feature with value of 0, label the button as "Off" and show status of "Off"
              If Shelly sends "true", then store in HS Feature with value of 1, label the button as "On" and show status of "On"


              We want to change it to be four buttons with unique labels. Shelly will never send a status for the two new buttons so we just pick any unique text. I used x and y below.

              Code:
              from
              false=0;Off;Off
              true=1;On;On
              to
              false=0;Off-Mini;Off
              true=1;On-Mini;On
              false=2;Off-1PM;Off
              true=3;On-1PM;On​
              ​


              Click image for larger version

Name:	image.png
Views:	99
Size:	16.8 KB
ID:	1655540

              The easiest way to make this edit is to copy the inner VSP line (black text between Payload and VSP) and paste it into the text box below and make the changes in the text box.

              In the HS Tile it will look like below. The status is being shown for the OFF-MINI and ON-MINI buttons. The status for the other features is only visible by drilling down through the corresponding icon in the tile's top row. In your case it may be adequate to just see the icon image/color to know the state of each of the two.

              Click image for larger version

Name:	image.png
Views:	52
Size:	20.5 KB
ID:	1655541

              The second part of issue is on the backside when pressing a button with intent of publishing a MQTT message to effect the desired control. You now have two published topics defined with one for each endpoint (row in MQTT Association table).

              Since one of these was extended with additional buttons, the Pub Payload of each needs to change depending upon which button was pressed. The Payload Template for the Shelly Gen2 mini On/Off buttons is the same format as all Gen2 On/Off buttons.
              Code:
              shellypluspmmini-a8032ab2dba8/rpc
              {"id":1,"src":"mcsMQTT","method":"Switch.Set","params":{"id":0,"on":$$VSP:}}
              The params id is the channel number so will be 0 or 1 for a Shelly25. The $$VSP: will represent the true/false state based upon the HS Control Value. To generalize the Template the id parameter can be made an expression where VSP definitions values of 0 and 1 for channel id 0 and 2 and 3 for channel id 1. The on parameter is false for values 0 and 2 and true for values 1 and 3. Below is an untested approach to the template.
              Code:
              {"id":1,"src":"mcsMQTT","method":"Switch.Set","params":{"id":<<IF($$VALUE: < 2,0,1) ,2>>,"on":<<IF(MOD($$VALUE:,2) < 1,"false","true")}}
              Once you edit the channel 0 Pub Template, you will likely want to delete the Pub Topic on the channel 1 so you do not have duplicate controls available for this second channel.

              As you indicated, this is only about how buttons are rendered on the HS Tile. Since this is the realm of HS, all I can offer is an alternate mechanism to show the buttons to work within the today's constraints imposed by HS. I doubt if a change request would be acted upon since this is primarily cosmetic and not a functional limitation.​

              Comment


                #8
                I have similar devices using esp mcu boards, such as a D1 Mini running Tasmota in place of the Shelly units. The MCU I use is based on the number of buttons as I use 2 output pins for each backlit button. For instance, one has 6 buttons with each controlling the backlight, sending an MQTT message, and also controlling a relay for an irrigation zone. Besides being less money, this also allows me to use long and short presses as well as multi press options if I so desire. My above mentioned irrigation controller uses a long press on any button to turn off all the zones. I use an MQTT plugin for this and other things and get parent/child devices by default since they all fall under the same topic. Just an to option to consider for future devices.
                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

                Working...
                X