oberkc

Don't forget to check your "content-length". As I stated earlier, mine is different for ON and OFF resources. For me, everything else is NOT necessarily the same.

This is what I have in my body field, and it works: {"on": false} The only thing I see different is a space between the ":" and the "f". However, I also notice that there are also some differences in the headers. Specifically, I notice that the "content-length" is different for OFF than for ON

I use the light switch that controls the flood lights as a trigger. If turned on manually, I disable the motion timer program. If control light switch is turned on and control light switch is not turned off then nothing else nothing That program is true if I manually turned on the switch, and false if I manually turn it off. Now I can simply use the true/false status as a condition of the motion timer program. If time is from dark to light and control motion sensor is on and status first program is false then turn on light wait a while turn off light else nothing Assuming that the switch is not manually turned on, the first program will be false and the timer program will operate normally. If the switch is manually turned on, the second program will evaluate false and nothing will happen (and will interrupt the timer if ongoing...a good thing). I would likely find it necessary to add a third program to handle the program timer being interrupted during the transition to "light" if time is light then turn off light Yes, you could use variables. You could also do similar logic with program folder, or by using a program to halt and disable the motion program. Whatever makes sense in your mind. Hopefully, this will give you some ideas.

Ah. I should have been more specific. Good.

Temporarily power your PLM from a long extension cord from another circuit. Does this help? Regardless, I would filter all that computer stuff. I don't care how long it has worked before. Things get old and things stop working. Your PLM is too important to risk interference from that other stuff.

This sounds like "marginal" communications, potentially. Your PLM...is it on a circuit with lots of other computer stuff?

I see nothing wrong with the program. It should work, in my estimation, without the scene. Normally, I understand direct commands are more robust than a scene. You could certainly temporarily add some wait states between each to see if lilyoyo1's theory checks out. I suppose it might be a link record issue, but this seems unlikely since they individually work from the admin panel. There seems to be a lot of talk about PLM failures. Perhaps that is a possibility here, but I have no idea how to determine that. Otherwise, I am running out of explanations.

I have had a dimmer cycle between off and on repeatedly. Is that what you are seeing? In my case, it was a device failure. Definitely check the program logs, however. Maybe Gary Funk is correct and you have a program that has found itself in some sort of loop.

Then I would look at communication issues. In the outlet and circuit that powers the PLM, are there lots of other electronic devices, such as computers, modems, printers, UPS, power supplies? Have you confirmed communication between the legs of your electrical system?

Clearly the admin panel should be showing accurate status. If not, programs won’t work. Whether you have link record issues or communication interference, this needs to be identified and corrected. If the steps in the linked wiki article does not solve the problem, you should begin troubleshooting potential sources of interference.

I use a scene. I do not believe that there is an ALLOFF command available.

I wonder if you could use one of the notifications. Depending on your cellular network, one can send an EMail message and receive it as text. (or, at least, one could in the past.) For example, sending an EMail to xxxxxxxxxx@vtext.com (xxxxxxxxxx = your phone number) would send a text message to your Verizon phone. Other carriers have similar capability. Perhaps that would work for you.

I wonder, given the modem restoration having solved your problem, if this is a sign of impending PLM failure.

I took the program listing as conceptual, not using strict syntax. For the purpose of someguy's question, that was sufficient in my mind.

I understood that a program such as this would continue to the end, unless it had wait, or repeats, in the statement. A change in the condition would NOT halt it, I thought. Perhaps this aspect has changed. Certainly, I would try stusviews recommendations.

Mr Bill. Perhaps I am confused. Your two examples: from sunrise to sunset (same day) from sunset to sunrise (next day) are clearly opposite time periods. I would not expect both to behave the same. Compare that to the original (post 1) program from sunset to sunrise (same day) Moving back to the cooper0705 program...I agree, let us keep it simple. I continue to think that there are no more problems beyond the "same day"/"next day" condition and remain unclear regarding your earlier post (#6) It is this condition that I find flawed, since sunrise (same day) occurs BEFORE sunset.

MrBill. I am not so sure this is accurate (or is at least misleading). While the sunset and sunrise conditions trigger only twice each day, they would be true at all points in between. I use the from-to condition in several programs. Works like a champ.

Ah. Thanks.

Yes, it is that simple, or even simpler, depending on what you are trying to accomplish. If you want a light to come on with the door, staying on until it closes, you could create a scene with the IOLinc relay as controller and light as responder. If you want a bit more control over when the light turns on and off, a program may be needed. Yes, it should be that simple. In your program, you might want to change your sunrise condition to "next day".

Yes, it is. But the title of your post suggest some concern about using the hue and ISY in the same room, and I still don't see a question. Perhaps none is intended, and you are only trying to point something out for others to be aware. If this is the case, thanks. But...if your intention is to seek input from others, it might be helpful to state your questions.

Benefit of hue versus ISY? The hue hub has very little automation, but apparently integrates with a bunch of other things such as the harmony and echo. I have been assuming that the ISY communicates to the hue system via the hub (network resource) so I view the hue system as a supplement to insteon and the ISY. My interest has been the color options, wall wash lights, and strip lights...those have worked out very well.

Is there a questions somewhere? I would think that the physical location of the hue and ISY would be irrelevant. They communicate via the local network, and both are wired, correct? Mine sit right next to each other.

My experience is much based on single-band devices, so it may not be as important as it once was, but I filter all UPS and surge suppressors as a mater of course.

Is the UPS filtered? Is it on the same circuit as the PLM? In my experience, those things cause problems for insteon signals. If you temporarily remove the UPS, does the problem go away?

Sometimes, power supplies of such systems can interfere with communications. (Sometimes not, however.) I have a few of those types of fixtures, and my system seems to work. Every now and then, though, one of those does not turn on when expected. Whether it is due to the power supplies or something else, I have never bothered to attempt to isolate. My gut feel is to go ahead with your plans if you are really sold on those fixtures. But, I would keep looking at other fixtures in case there is something you missed that you would like just as well. Besides, do not LED bulbs have little internal power supplies? I am not sure one can avoid them.