Model concept misunderstanding - Equipment with unlike channels that accept same commands

Setup, Configuration and Use Beginners
, ,
1
  • Platform information:
    • Hardware: x86/16GB/1TB
    • OS: Linux/5.4.0-94-generic (amd64) - Ubuntu 20.04
    • Java Runtime Environment: 11.0.13 (Zulu11.52+13-CA)
    • openHAB version: 3.2.0, Docker

I was reading a few comments here and it got me thinking about how I’m setting up my model. I was hoping you all could help me clear up what I think may be a conceptual misunderstanding I’m having.

I’ve read that the model should be a physical representation of your house. An equipment, for example, should contain all the points you want to control. The equipment should exist in one place, as one unit. As I understand, it should look something like this:

  • Group: Living Room
    • Group: Lights
      • Group: Overhead Lights
        • Equipment: Light bulb 1
          • Point:Color
          • Point:ColorTemperature
        • Equipment: Light bulb 2
          • Point:Color
          • Point:ColorTemperature
        • Equipment: Light bulb 3
          • Point:Color
          • Point:ColorTemperature
      • Group: Floor Lamp
        • Equipment: Light bulb 1
          • Point:Color
          • Point:ColorTemperature
        • Equipment: Light bulb 2
          • Point:Color
          • Point:ColorTemperature

In practice, I’m struggling to do that. It may have something to do with my light bulbs.

For context, I’m using TP-Link KL130 bulbs with only two controllable channels: Color and ColorTemperature. The Color channel seems to double as a dimmer (for the current color or color temperature setting), so sending 0 to Color is off, 100 is full brightness, etc. Sending 150,150,150 or something to that channel would result in a color. ColorTemperature also works on 0-100. The concept to note here is that both channels of each bulb can accept the same command (e.g. 35), but do different things with it–things that shouldn’t happen together.

Most of these lights need to be controlled together. Ceiling light fixtures will have 2 or 3 lights, or a room will have maybe 4 or 5 total that all need to turn on, dim, adjust color temperature, or change color in tandem.

Now, I have that working fine–great actually, but how I got it working is the point of confusion that I think you all have the experience and understanding to tell me if it’s okay or totally off-base.

Because groups share commands down to everything in them, I can’t seem to represent the bulbs in the same piece of equipment. If I have a group “Lights” and an equipment for each light bulb under it, and each bulb has its points corresponding to the bulb’s channels, the commands I send to “Living Room Lights” fit within the parameters of multiple points. If “Lights” is a dimmer, and you send 35 to it, that 35 also goes to the ColorTemperature points, and is valid.

This problem occurs in reverse, too. Because stuff can only have one base member type and one aggregation function, I don’t understand how I’m supposed to have equipment with multiple points reporting different types of data–I lose the ability to see the aggregate status of and control any points not matching the base member type. A group can’t be a dimmer and a color at the same time, even if the lights under it are dimmable and colorable. Moreover if the dimmer and color temperature are all reporting values 0-100, no aggregation function will return an accurate representation of either since they’ll be mixed together.

This seems to break the idea that the model should be a physical representation of the house, at least in my case, if I’m understanding correctly.

My workaround has been setting my groups up like this:

  • Group: Living Room
    • Group: Lights dimmer (LivingRoomLightsDimmer)
      • Group: Overhead Lights (LivingRoomOverheadLightsDimmer)
        • Point:Color
        • Point:Color
        • Point:Color
      • Group: Floor Lamp (LivingRoomFloorLampDimmer)
        • Point:Color
        • Point:Color
    • Group: Lights color temperature (LivingRoomLightsColorTemperature)
      • Group: Overhead Lights (LivingRoomOverheadLightsColorTemperature)
        • Point:ColorTemperature
        • Point:ColorTemperature
        • Point:ColorTemperature
      • Group: Floor Lamp (LivingRoomFloorLampColorTemperature)
        • Point:ColorTemperature
        • Point:ColorTemperature

All of those groups are dimmers, except the parent group “Living Room” in this example, which isn’t touched. I’m leaving off how I got color working here since Groups of type Color don’t currently exist in 3.2.0, so that took some spicier misuse.

What this allows me to do, though, is have cards in my UI with multiple sliders on them for whole-room dimming (targeting item LivingRoomDimmer) and color temperature (targeting item LivingRoomLightsColorTemperature), or cards targeting individual lamps (multiple bulbs) for the same.

This doesn’t gel with what I’m reading about how a model should look, though. Could anyone explain how I’m going wrong here, and what the solution may be? I feel like I’m missing something big and obvious.

Thanks!

2

Welcome to the forums!

I don’t think you’re missing anything to big here. Perhaps the only piece that might help is to remember that you don’t have to use the model and you certainly don’t have to put everything in the model.

There are some ideas floating around on how to expand the usability of the model, but for the moment, the model only really applies in a few specific cases. 1) If you’re going to use HabBot then the model provides the semantic information for HabBot to understand commands like “turn off the kitchen lights”. 2) The extra tabs on the startup screen of the UI (equipment, location, properties) are auto-populated based on the semantic model information. 3) Some of the widgets available in the widget marketplace do take advantage of semantic tags to aggregate certain types of items (e.g., batteries).

If you’re not going to be utilizing one of the above, then you probably don’t have to spend too much time worrying about it. I personally do have a fairly extensive model, but I don’t use HabBot, I rarely use the automatic pages anymore. I do have a few widgets that rely on semantic tags and I find the model page a very efficient way to administer my items and links in certain situations. But, if the model doesn’t fit your use case that’s ok, carry on without it.

As to your specific issue, I personally would keep your initial model arrangement; I agree that fits pretty well with the general philosophy behind the model. To fix the issue with groups, I’d just make another group item which contains all the Color items for the bulbs that need simultaneous control… This item doesn’t have to be part of the model (though I do have a few cases in my setup where such a group is actually a point of a location such as the group controlling both beside lamps in the master bedroom).

1 Like
3

That’s really good feedback! I don’t intend to use HabBot since I have Rhasspy handling spoken commands, and that’s close enough for me. It’s already sending MQTT to a broker thing in openHAB such that if I say “dim the living room lights to 35,” it will do so with the current model by sending 35 to LivingRoomLightsDimmer.

I also don’t intend to use the auto-populated tabs since I’m setting up my own structure where you click into a floor, then click into a room, then get a custom page with cards showing all the device groups with associated controls and an image matching their current state.

I guess I was mostly concerned whether how I’m setting things up is likely to come back and bite me later. The only other way I could immediately think to do it would be having one bulb (real or imagined) act as a control bulb for others, and then using rules to send the commands exactly where I wanted without landing in situations where multiple channels picked up the same command and ran with it, even if they weren’t supposed to. That seemed to have just as many unknowns and caveats down the road too, though.

Thanks for your perspective on this!