oberkc

Logged into new app. All seems to work, based on quick check and adding of favorites.

Ok. I just looked it up and downloaded to my phone. It seemed to download fine (android version 11). Unfortunately, I will have to wait until later to go any further, since I do not have my portal login credentials.

I suspect that your android OS is too old. In the play store, in the app description, is there not an eligibility requirement for andoid?

I have never learned to read those logs. My perception is that garage door openers can be a serious source of interference when they are running. Is that a possible explanation for what you are seeing?

This is true (at least older versions). The relay does not transmit status and cannot be used as a scene controller. Thanks for the update to your trigger reverse and query. Hopefully, that will remain solid for you.

Thanks. The only problem with "trigger reverse" that I recall is that this setting does not apply when queried. So...if you have the typical 3:00am query, this might cause a state change for the sensor. Any program that might be triggered by a state change would run. Also, I assume it would render the KPL buttons being inaccurate until toggled again. Perhaps this has been fixed in newer versions of the IOLinc? Are you experiencing this problem?

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.