oberkc

It looks as if your scenes are set up correctly. I must admit that I don't understand why your sensor (indicated by green LED in third picture) is ON but the status as shown in the ISY admin panel pictures show OFF. Do you have sensor reversed in the IOLinc settings? Otherwise, I don't see anything else outside the normal. I assume you have relay mode set to momentary, and KPL button set to non-toggle mode?

1) The "SENSOR" is on when the door is closed. The relay is unaffected by the door position. Whether the sensor life is degraded by having the 5V applied a majority of the time (assume closed more than open) I do not know. 2) I don't think that the sensor being on or off will affect mobilinc operation. I performed a quick check on one device on mobilinc (mobilinc pro on UD portal, in my case) at my house, and it looks as if the mobilinc states updates less than 10 seconds after something changes at home. If your mobilinc is not doing this, I doubt it has anything to do with the IOLinc. My two IOLinc sensors appear to be tracking correctly on mobilinc.

OK. Since the new sensor is ON when the door is closed, the KPL button will now be ON when the door is closed. Yes, I suspect that you had the original style sensor which had both options. The new one does not have both options. I believe you have a couple of options... - keep using the original sensor with the new IOLinc. (Assumes the sensor is still good.) - Purchase a new sensor having the "normally closed" option - mount the sensor in a location such that the magnet is close to the sensor when the door is fully open (less desirable in my estimation) - use a program (rather than a scene) to trigger the KPL backlight

LED on = sensor on Having said this, there is no single right answer. It all depends on how you intend to use the sensor status in your system and how you want the system to behave. How was your old sensor used? As part of a scene? As part of a program trigger? Other?

I do not believe this is true. I ran the series 300 board all the way through 5.0.16. I believe that the need to go to 500-series board is related only to 5.2.0 One thing that caught my attention on your post is that you have 5.0.13 software and 4.7.3 UI. Mismatch between software and UI seems to be a common topic and have unpredictable results. If you are having issues, you may want to resolve this problem first.

There were, if I recall, things added to the 5 level that could not easily be done at level 4. Whether they are benefits to you, I cannot say. I also do not remember them all but one that I do recall was the introduction of a robust set of system variables. For me, the ability to add program conditions based upon year, month, and day was quite useful. I understand, too, that there may be a small number of devices supported in 5.x that are not supported in 4.x. I believe there were some z-wave improvements as well. Only you can know whether this is beneficial to you. It does seem that there is a large number who are staying on 4.x. Some seemed to fear (until recently) the fact that it was classified as "beta". Other probably wanted to avoid the work entailed. Sill others saw no benefit. It all depends on your wants and needs, I guess.

I use mobilinc pro with the ISY portal. I can use moblinc pro without ANY portal access, which I like, but have the portal for other reasons, so I decided to go through the portal for app access due to perceived improvements in security. I do not use mobilincX (or whatever the latest version is). Also, access to my system via phone or tablet is not the highest priorities for me. I don't really care if an app "looks" dated, nor do I have much need for access to toggle more than a few scenes or devices on phone. I understand that mobilincX may have some features that are lacking in mobilinc pro, but pro still does all that I care about. I wonder, however, how long it will continue to work. I don't like relying on the cloud for my system to work. I also don't like subscription services. Having said these things, I chose to subscribe to the ISY portal for a variety of reasons (totally unrelated to mobilinc). I think if I were to loose my current mobilinc pro function, I would probably abandon mobilinc for some other solutions, possibly including google home or alexa, or the dashboard (requires ISY portal, I think.) I will cross that bridge only if I must.

I recall, during my initial conversion from 4.x to 5.x software (I don't remember exactly which was my first version of 5.x software) many of my programs had errors such as these. Even now, I see the note in the instructions: Upgrading to this version may require a lot of manual intervention including verifying scenes, programs and program settings are correct. In some cases it will be easier to rebuild your network. For programs that now contained errors where there were once program statements, I recall them having yellow icons in the listing. For each of these, it may be necessary to manually correct these errors before going any further. Try correcting one of the faulty programs and see if this solves the problems with that particular program.

I can't say much regarding mobilinc app. I recall that there were different benefits to each, but don't remember exactly what those benefits were. It seems possible to me that this is contributing to some problems, but I perceive that the Polisy/ISY interface is direct over your LAN and I would not expect a portal connection to interfere with the communication between the two devices.

One thing I don't see mentioned is the possibility that your ISY has a new IP address (from power outages, or rebooting of the router for whatever reason). Do you have a static address configured in your router? If the address has changed and the polisy is looking for the original address...well...this probably won't work out. I suggest double-checking the ISY address and seeing if it matches the address configured in the Polisy settings.

Did you ever use network resources to control Hue lights? Is it possible this program is calling up a network resource?

I have never had a mismatch of ISY versus UI. Every time I have upgraded, the UI followed with the rest of the system. I do not believe that there is a separate upgrade process for the UI versus the rest of the operating system. Given this, I can offer a couple of thoughts: - You could try the update again (not sure about the risk) - make sure you are using the correct launcher. Instructions say to use: http://your.isy.ip.address/admin.jnlp - clear your Java cache

On a slightly related topic...we have had a couple of windy days lately, causing some momentary power outages. After each outage, I notice that my hue lights are no longer controllable via ISY and the polisy says it is not connected to the ISY. I am currently operating under the theory that the polisy boots up faster than does the ISY and, during power outages (and, perhaps, purposely unplugging both) the polisy may be looking for the ISY before the ISY is online. Resetting the connection, or individual node servers, seems to solve these problems. I expect that unplugging the polisy would work as well, but not if you simultaneously unplug the ISY. Both my ISY and Polisy are on their own UPS now.

No. "AND" takes a natural priority over "OR". The parentheses simply duplicate the natural hierchy of Boolean logic. If, for example, switch1 is toggled on, the individual condition "switch1 is controlled on and switch1 is not controlled off" would be true, and the entire condition would also be true.

From a pure logic statement, I don't believe adding the parentheses changes the logical outcome.

Can you see any relationship between when you program does not work and when the washing machine is running? Given the critical nature of the PLM, I tend to like having it on its own circuit or having anything else on that circuit filtered. Regardless, it sounds as if you are having intermittent communication problems and you need to identify the source.

Even if your primary device is not showing status change, it may be worth trying something... For the zwave device in question, right-click>>z-wave>>>add/refresh button press node. This might add an additional node for that device that can be used in programs to trigger things. Give it a shot.

Sorry for the misdirection, @phatmatt. Thanks to lilyoyo for getting it right.

I had very similar experience...updated board, updated firmware. Switches that once reported status no longer do so. It is, indeed, my understanding that this is a UD issue and that there is a fix coming.

There are probably opportunities to use scenes here, but below is a programmatic approach. I made the assumption that there is no harm in turning off switches that were already off. if status switch1 is off or status switch2 is off or status switch3 is off or.... then turn off switch1 turn off switch2 turn off switch3 turn off....

I, too, have had a difficult time recently with Z-wave. It got worse when I upgraded to software version 5.2, along with replacing z-wave card with newer version. Switches that used to update status no longer did so. In some cases, I could partly resolve the problems by removing the z-wave device, resetting it, and adding it back. In one case, I replaced it with a new one. In the end, I got a response from the company that told us that these problems were going to be resolved in a software update. This experience would only be relevant to you if you are on 5.2 firmware.

So...it looks like it last ran today, and ran TRUE, as expected. Given this, I expect that it runs consistently every day at sunset. I would focus on comm problems. Do all the lights come on when it works? Do all the lights not come on when it does "not work", such as yesterday? Your PLM....is it located on a circuit with lots of other electronic devices? Computers? Printers? Routers? Chargers? Power supplies? UPS?

After adding the parentheses, you will likely need to move these to the proper location in the program.

You will probably need some parentheses in your condition. Add them ahead of the first line and after the third.

I am assuming you are using insteon devices. For the bathroom, it sounds as you want motion detection to turn on light automatically, and off again in 5 minutes, when walking into a dark room. Additionally, you want a manual control of the light to disable the motion response, but the lights to automatically turn off in an hour when manually turned on. (I will not address the risk of someone walking into a fully-lit bathroom at minute 59 and the reaction when the lights go out at minute 60). You could use scenes and MS settings for some of this, but I will address entirely from programs, assuming there are no scenes involved. Forgive the inexact wording of the program language: Program 1 if control motion sensor is on then turn on light wait five minutes turn off light Program 2 if control light switch is turn on And control light switch is not turned off then disable program 1 wait one hour turn off light swith enable program 1 else enable program 1 For the driveway program, you do not state what you want to happen, if anything, when driveway motion is triggered and it is not late at night, so I will assume nothing. . Program 1: if control driveway motion sensor is triggered and time is from late at night to not late at night then run program 2 (then path) program 2: if nothing then enable program3 wait thirty seconds disable program3 Program 3: if front door is triggered then turn on hallway light wait 2 minutes turn off hallway light