Best Practices at the start

Posted on
Sat Apr 02, 2016 12:18 pm
Different Computers offline
User avatar
Posts: 2533
Joined: Jan 02, 2016
Location: East Coast

Best Practices at the start

I searched the forums for some best practices, but it all seemed to be best practices about one specific thing.

I find myself wondering about best practices at the very start of things.

Now some of my concern may be because I don't really "get" Indigo yet. I'm working on it, but I'm on day 2, and only have 1 z-wave device moved over so far!

But here are some things I find myself wondering about that might help you understand what I mean about starting off right:

    Is presence a variable, or a trigger? Is it both?

      Are "modes" for the house as a whole mandatory, nice, or useless? I'm thinking of "Sleep/Nice Day/Overcast/Night/Away" kinds of modes. These were critical in SmartThings, if only because of ST's very limited logic that meant modes are critical for if/then situations.

        Is it important to keep folders named the same across Devices, Triggers, and Action Groups, as was the case with the demo?

          Should I delete the whole demo database, rather than build on it? Seems like there's some variable logic built in that might be useful.

            If you were faced with totally rebuilding your Indigo setup from zero, then based on all you've learned from putting it together once, how would you do it better?

        SmartThings refugee, so happy to be on Indigo. Monterey on a base M1 Mini w/Harmony Hub, Hue, DomoPad, Dynamic URL, Device Extensions, HomeKitLink, Grafana, Plex, uniFAP, Fantastic Weather, Nanoleaf, LED Simple Effects, Bond Home, Camect.

        Posted on
        Sat Apr 02, 2016 4:07 pm
        Busta999 offline
        User avatar
        Posts: 714
        Joined: Mar 30, 2016
        Location: Wales UK

        Re: Best Practices at the start

        Hi, I'm on day 4 of Indigo going through same questions, device naming convents etc. I have about 30 items moved across now. Hopefully they are named sensibly and won't require a rename later


        Sent from my iPad using Tapatalk

        Posted on
        Sat Apr 02, 2016 7:42 pm
        FlyingDiver offline
        User avatar
        Posts: 7189
        Joined: Jun 07, 2014
        Location: Southwest Florida, USA

        Re: Best Practices at the start

        Busta999 wrote:
        Hi, I'm on day 4 of Indigo going through same questions, device naming convents etc. I have about 30 items moved across now. Hopefully they are named sensibly and won't require a rename later


        Renaming doesn't cause any issues, as the Device ID doesn't change. Just make sure you reference devices by ID in any custom scripts, not by name.

        joe (aka FlyingDiver)
        my plugins: http://forums.indigodomo.com/viewforum.php?f=177

        Posted on
        Sun Apr 03, 2016 9:39 am
        Different Computers offline
        User avatar
        Posts: 2533
        Joined: Jan 02, 2016
        Location: East Coast

        Re: Best Practices at the start

        Here's another best practices question.

        Is it better to set a variable (or pair of variables, perhaps) and set an Action Group to set devices based on that variable, or to have two Action Groups that do different things based on that variable?

        Here's the concrete example:

        All Exterior Lights set to off Action group runs 23 minutes before sunrise, and turns all the outside lights off. If there's a way to make the same action group turn on at 23 after sunset, I don't see it. So I would need another action group that does this.

        But I could, I think, set a variable at sunset with a value of 100 (for example) and use that value for the exterior dimmers and as the value that causes an ON condition for non dimmers. Then set that value to 0 at 23 minutes before sunrise. Then there's just 1 action group.

        Best practice?

        SmartThings refugee, so happy to be on Indigo. Monterey on a base M1 Mini w/Harmony Hub, Hue, DomoPad, Dynamic URL, Device Extensions, HomeKitLink, Grafana, Plex, uniFAP, Fantastic Weather, Nanoleaf, LED Simple Effects, Bond Home, Camect.

        Posted on
        Sun Apr 03, 2016 9:45 am
        FlyingDiver offline
        User avatar
        Posts: 7189
        Joined: Jun 07, 2014
        Location: Southwest Florida, USA

        Re: Best Practices at the start

        Don't make it more complicated than it needs to be. You have an "Outside Lights On" group and an "Outside Lights Off" group. Easy. Unless you have some logic somewhere that you would want to vary the brightness of those lights over time, you don't need the complication of the variable.

        joe (aka FlyingDiver)
        my plugins: http://forums.indigodomo.com/viewforum.php?f=177

        Posted on
        Sun Apr 03, 2016 12:13 pm
        Different Computers offline
        User avatar
        Posts: 2533
        Joined: Jan 02, 2016
        Location: East Coast

        Re: Best Practices at the start

        But IS that more complicated? In one case I have two groups (that have to be built of various parts and kept up to date) and in the other I have ONE group and one variable.

        Imagine if I decided I want my GE Link bulbs to come on at 50 % starting at Sunset until full dark. If I don't do a variable, I have to create another group entirely for that 40-ish minute window of time/behavior.

        I'm all for simplicity. But I wonder about how to achieve it. Hence my calling for best practices.

        SmartThings refugee, so happy to be on Indigo. Monterey on a base M1 Mini w/Harmony Hub, Hue, DomoPad, Dynamic URL, Device Extensions, HomeKitLink, Grafana, Plex, uniFAP, Fantastic Weather, Nanoleaf, LED Simple Effects, Bond Home, Camect.

        Posted on
        Sun Apr 03, 2016 12:18 pm
        FlyingDiver offline
        User avatar
        Posts: 7189
        Joined: Jun 07, 2014
        Location: Southwest Florida, USA

        Re: Best Practices at the start

        Different Computers wrote:
        Imagine if I decided I want my GE Link bulbs to come on at 50 % starting at Sunset until full dark. If I don't do a variable, I have to create another group entirely for that 40-ish minute window of time/behavior.


        That's exactly what I meant about changing the value over time. If you think you want to do that, then going with a variable makes sense.

        On the other hand, what if you have different lights that need to be at different percentages? Then one single variable doesn't do it, or you need to do a calculation for each light type to get to the correct value. On my house I have soffit lights and coach (sconce) lights. Plus landscape lights. If I want all those to be different light levels at different times, it's a lot more complicated.

        joe (aka FlyingDiver)
        my plugins: http://forums.indigodomo.com/viewforum.php?f=177

        Posted on
        Sun Apr 03, 2016 1:28 pm
        howartp offline
        Posts: 4559
        Joined: Jan 09, 2014
        Location: West Yorkshire, UK

        Re: Best Practices at the start

        For this example, look at the virtual devices plugin.

        Turn your outside lights on manually, to the brightnesses you want them, then create a virtual device called outside lights and select which lights you want it to include.

        When you turn ON the virtual device, they will go to the STORED settings (hence turning them on/dim before you start). When you turn OFF the virtual device they will go OFF.

        I'll check my wording when I'm at my desk shortly.


        Sent from my iPhone using Tapatalk

        Posted on
        Sun Apr 03, 2016 2:07 pm
        howartp offline
        Posts: 4559
        Joined: Jan 09, 2014
        Location: West Yorkshire, UK

        Re: Best Practices at the start

        Different Computers wrote:
          Is presence a variable, or a trigger? Is it both?

            Are "modes" for the house as a whole mandatory, nice, or useless? I'm thinking of "Sleep/Nice Day/Overcast/Night/Away" kinds of modes. These were critical in SmartThings, if only because of ST's very limited logic that meant modes are critical for if/then situations.

              Is it important to keep folders named the same across Devices, Triggers, and Action Groups, as was the case with the demo?

                Should I delete the whole demo database, rather than build on it? Seems like there's some variable logic built in that might be useful.

                  If you were faced with totally rebuilding your Indigo setup from zero, then based on all you've learned from putting it together once, how would you do it better?

              Presence is natively a variable, though if you are using the Beacon plugin or similar, it might be a device.

              Modes are certainly useful, but it depends on your usage as to whether they're mandatory - if you want to automate your house, so it does things itself, then they're probably mandatory. If you just want a nice common interface to lots of products (zwave, Insteon, Hue, Alexa, etc) then useful but not mandatory.

              Naming convention is entirely up to you; nothing in Indigo uses the folder names other than yourself and your users, unless you start scripting and writing plugins that use the folders. However it does make sense to have consistency. Some users do it per room, some do per type. (Kitchen, Lounge, Study, or, Motion, Lighting, Security)

              Leave the demo database as it is and create a new one.
              howartp wrote:
              For this example, look at the virtual devices plugin.

              http://wiki.indigodomo.com/doku.php?id= ... nterface&s[]=virtual

              Sorry, I called it a plugin, but it's built in by default, just turned off.

              You want a Virtual Devices > Device Group, not a Virtual Device > Virtual On/Off Device.

              As I said, set your devices (kitchen light, door light, path light, drive light, garden light) to the state you want - ie on and <x> brightness.

              Then create a Virtual Devices > Device Group. Multi-select those lights in the list provided.

              If you aren't going to view the status of this device manually ("Are any or all of my outside lights turned on?") then you can ignore the rest of the boxes. They determine when the device shows as On or Off in the device list in Indigo and Indigo Touch etc. By default, if any of the lights are On, the virtual device shows On. I tend to set mine to 'when all devices are on' so it only shows on if they are ALL on.

              You don't need to hit 'update' at this point, just hit Save.

              Now when you turn Off this device, the lights you selected will all go Off. When you turn ON the device, they will go to the stored state.

              If you add a new light that you want to include in the group, just set it to it's desired state, edit this virtual device, add it to the multi-select, and hit Save. It will add the new device to the group without affecting the saved state of the other devices. If you want to edit the state of a device (say the dimmer brightness) then you need to set them all to their desired new state and tick 'Update all' before hitting save.

              Hopefully that makes sense; what gets people often is that if a selected device's state is OFF when you save the state, then turning ON the virtual group will turn OFF that device.

              Peter

              Posted on
              Sun Apr 03, 2016 2:58 pm
              Different Computers offline
              User avatar
              Posts: 2533
              Joined: Jan 02, 2016
              Location: East Coast

              Re: Best Practices at the start

              VERY helpful!

              I wouldn't have tried virtual devices because I'm hard up against the trial's 20 device limit.

              But I'm lost about where you say presence is natively a variable. This is not obvious to me. How?

              SmartThings refugee, so happy to be on Indigo. Monterey on a base M1 Mini w/Harmony Hub, Hue, DomoPad, Dynamic URL, Device Extensions, HomeKitLink, Grafana, Plex, uniFAP, Fantastic Weather, Nanoleaf, LED Simple Effects, Bond Home, Camect.

              Posted on
              Sun Apr 03, 2016 4:07 pm
              howartp offline
              Posts: 4559
              Joined: Jan 09, 2014
              Location: West Yorkshire, UK

              Re: Best Practices at the start

              Indigo has five areas in the main UI:

              Devices
              Schedules
              Triggers
              Action Groups
              Control Pages

              Then, hidden away in the menu is Variables.

              Is "presence" a device? Can you 'switch on' the fact someone is here or not?

              Is "presence" an action? I'm jumping up and down - does that mean I'm here?

              Etc

              Presence is, fundamentally, a true/false state, which is ideal for variables.

              Now, that's not to say you can't represent presence as a device - I have several iBeacons that are devices in Indigo. They are On/Off states - I can if I stand in my lounge be present at all three house iBeacons at once. But I have triggers on them that update a set of variables. One holds my latest location (iBeacon), from which a control page shows my location, four are called 'isHome', 'isDriving', 'isChurch' and 'isWork' which are the four places I spend my life, and are duplicated for my parents.

              So presence is as you desire it, depending on the technologies and applications available to you - but natively out of the box it's a true/false status held in a variable.

              IMHO, YMMV. :-)


              Sent from my iPhone using Tapatalk

              Posted on
              Sun Apr 03, 2016 4:22 pm
              Different Computers offline
              User avatar
              Posts: 2533
              Joined: Jan 02, 2016
              Location: East Coast

              Re: Best Practices at the start

              My apologies.

              I either misread or misunderstood your comment about "naively a variable."

              I get it now. Thanks again!

              SmartThings refugee, so happy to be on Indigo. Monterey on a base M1 Mini w/Harmony Hub, Hue, DomoPad, Dynamic URL, Device Extensions, HomeKitLink, Grafana, Plex, uniFAP, Fantastic Weather, Nanoleaf, LED Simple Effects, Bond Home, Camect.

              Posted on
              Mon Apr 04, 2016 3:16 pm
              PvG offline
              Posts: 9
              Joined: Feb 15, 2016

              Re: Best Practices at the start

              The 'wasp in a box' model seems to be the most reliable way to determine occupancy of zones. Read this: http://dreamgreenhouse.com/projects/201 ... /index.php
              I use variables to implement this. Each zone can be in a state occupied, unoccupied or unknown. Zones can be nested. Zones can be open or closed (door sensors). Activity within zones is sensed in various ways: motion, light switches, TV on, etc. Works rather good. Logic:
              - closed & activity in zone --> zone=occupied & stop timer
              - opened (e.g. door opened) --> zone=unknown & (re-)start timer
              - open & activity in zone --> restart timer
              - zone=unknown for some time (timer expired) --> zone=unoccupied
              The timers are my way to deal with the uncertainty as mentioned in the article above. Therefore, the timer value depends on the usage of the zone: the whole house has a 30 min timer, the garage only 10 min or so. When a zone becomes unoccupied, all lights etc. are turned off. When the whole house becomes unoccupied, the alarm is turned on.

              For presence detection (who is or comes home?) I ping the smartphone of each family member (blocking ping, max. once per minute) and store the 'last seen' date/timestamp in a variable.
              Note that the presence of a smartphone does not imply that the house is occupied (the phone might be outside the house, but on the network... a wasp outside the box). Currently, I set the whole house zone to unknown in case a smartphone is detected. This allows to automatically turn off the alarm and switch on a light at the front door when the whole house zone state changes from unoccupied to unknown.

              My $0.02.

              Posted on
              Tue Apr 05, 2016 2:19 am
              IndigoSam offline
              Posts: 182
              Joined: Apr 14, 2013

              Re: Best Practices at the start

              Interesting thread.

              I use variables for modes (home/not home/evening/day/weekend/etc), but also as device buffers, especially when more than one device contributes to the variable value.

              An example if you have a light sensor:

                1. You could have a tigger on the device, when it reaches some low lux value, to do a bunch of things (say, turn on a porch light)
                1. You could have a trigger on a device, same logic as above, that sets a 'Low Light' variable to true. Then a trigger on that variable to turn on your light
              The second one looks like the first, but now it allows other operations that might be interested in it being low light (say a schedule) to reference the variable. This still isn't a big step up through, your schedule could have just checked the lux value on the device. However, it does allow you to swap out that device and just update the variable trigger once, without going through everything that relies on it.

                3. You have multiple light sensors. Each has a trigger on a specific lux value. When they trigger you can put some logic in to determine if you are going to set your variable to true.
              This allows for a consensus between the devices (2 are showing low lux, one isn't. Oh, there is a street light shining on it) or allows for a device to fail/give incorrect values. You can basically build a 'highly available' light level system. It also allows for different types of devices to contribute to the variable, for example an override switch that allows you to state it is dark out, no matter what the devices are saying.

              Best practice is an interesting concept and not one I have considered before. I think this is because I see Indigo as a 'toolbox' of options. There is rarely one way of doing things and you are not forced down a particular path. I suspect there are best practices though and I'm interested to see the contributions to this thread.

              I say that because I have realised I'm almost exactly 2.5 years into Indigo ownership and I have never used an Action Group or a Virtual Device!

              Sam.

              Posted on
              Sun Jun 12, 2016 11:20 am
              Different Computers offline
              User avatar
              Posts: 2533
              Joined: Jan 02, 2016
              Location: East Coast

              Re: Best Practices at the start

              Here I am again.

              I'm about to dive in to using Better Email plugin to receive status of some Zigbee door sensors from ST via IFTTT. I'm stopped for the moment at the point where I either have to define the open close states of these devices as variables, or Action Group Virtual Devices.

              I'm leaning toward variables, but I'm, as ever, interested in thoughts about what's the best practice. Is there a way of doing this I haven't even thought of?

              And further: One of these sensors monitors the deep freezer to make sure it isn't staying open long. I'm thinking a delayed trigger that gets canceled if the door closes. Elegant enough?

              SmartThings refugee, so happy to be on Indigo. Monterey on a base M1 Mini w/Harmony Hub, Hue, DomoPad, Dynamic URL, Device Extensions, HomeKitLink, Grafana, Plex, uniFAP, Fantastic Weather, Nanoleaf, LED Simple Effects, Bond Home, Camect.

              Who is online

              Users browsing this forum: No registered users and 5 guests

              cron