larryllix

Use the ISY function TestRandom - [ID 0102][Parent 0001] If $sTest.modulus_XX is not 0 Then $sTest.result_XX = $sTest.modulus_XX Wait 2 seconds $sTest.result_XX = Random 200 Else - No Actions - (To add one, press 'Action')

On that note: This depends on how tech savvy you are. Bulbs must have predefined IP addresses fixed inside your router's DHCP table. 15 variables need to be named for this usage. 4 for bulb parameters and 10 for a bulb list to be operated. 3-4 Network resources need to be defined. On/Off/SetLevels/Effects My software needs to be installed/copied in a folder on your Polisy/Eisy/ or RPi A line must be installed in the bootup system to make it run on boot-up A python file must be edited to match and define your IP addresses on machine above ISY programs need set up R, G, B, CW, and WW variables, and up to 10 bulb IDs wanted to be controlled for each command in programs. Bulb scenes are created on demand in programs and not preset. A NR needs to be called to initiate the command. Up to 10 bulbs will respond to the setting sent. Hardly any popcorn effect can be noticed with total time about 0.5 seconds for 10 bulbs. Many effects are built into most bulbs, including coloured flashing etc. No ISY looping required.

WiFi bulbs are around, and getting very commonly available, and cheap. EISY can control them natively without any further hardware. No hub, and no bridge with limited distances. They are fast and dimmable to 1% without flicker. There are many brands. I have been using MagicHome RGBCW/WW bulbs and CW/WW lamps for many years. I only have two Insteon lamps in usage now. At one time I had many Insteon controlled bulbs (never the bulbs themselves, but Insteon plug-in dimmers and wall switches.) Wifi will still be around when most of are dead.

Well, Thanks all your testing your MS II devices guys. Unfortunately, it seems I got stuck with three buggy MS II versions that don't perform as well as the 12 older MS I's I have , except for not requiring batteries every 8-13 months. Last night I retested my other two MS II units and they perform the same style with a blind time after on timeout. I should attempt a workaround for "send On and Off" as it appears to eliminate this blind time. AFAIK, the side parameters will never function properly and those values are only for internal compensations. The temperature register only appears to have a resolution of 2-4 degrees and wouldn't be useful for any HVAC style logic. This is based on the inability for ISY to set anything finer than this resolution. I think UDI in it's successful hacking exposed things that were never intended to be exposed outside the device.

The only way I could see working is to have ISY break the value down into Low, Medium, High, very High, Extreme, and create a variable for each and a routine to say the phrases for each. On that same technique multiple phrases and variables could be created for absolute temperature values but break them into larger lumps using the phrases with "greater than" inserted. eg: "Your temperature is greater than 72 degrees" "Your temperature is less than 68 degrees" It would take a few, of course but some careful thought of what ranges are critical can reduce the quantities a lot.

Your last line may be where the confusion comes in. IndyMike and I are saying that the MSII can be retriggered once the ON time has timed out at 40 sec+ ... your last line is now attempting to retrigger the device BEFORE the On time times out and thus it will not send more ON commands. If you don't wait you are re-extending the ON time by restarting it. Anytime you wait long enough for the ON timer to expire then a retrigger can be created and once again an ON command is sent. When configured for ON-ONLY there is NO OFF time. You must wait for the ON time to expire before retriggering if you want additional On commands to be sent. Read your last post again. 60 seconds has always been longer than 40 seconds, and always will be. The lights on timer have timed out at 40 seconds and at 60 seconds the lights and On timer inside the MS II should be doing nothing. It isn't. It is timing the off cycle now. EDIT: OK you are considering the lights/MS II to be in an ON cycle again. My MS II devices would still be in a locked out OFF cycle and will never trigger an On cycle again until motions stops for 40 seconds (same timer used for ON cycle). I have to assume there are different versions of the firmware inside.

That all works fine but the problem is when using "On Only" with ISY programs for retriggering the MS II will not send another motion detected signal while the Off timer has not expired and the Off cycle timer will never expire as long as it is seeing motion. Try this: -Set your MS II to "Send On" only. -Set your MS II to "40 seconds" -Create motion and turn lights on. (time = 0 seconds) -Allow program and MS to time out ( >40 seconds) -At about 60 seconds (20 seconds later), start creating motion. -Create motion about every 10 seconds, for the next few minutes. Don't miss. Does the MS II ever blink green, indicating "On" is being sent.... or, does your program ever get triggered by the MS II? This is the "blind period" I am referring to. This is not the On time to Off delay period, although the same internal timer has been used for this "blind" period. -Stop motion for 40 seconds, and then create motion again. MS II should blink green and program should get triggered again. My MS II units are all datecoded: 17 15. All the same manufactured date, despite them being purchased at many intervals, months apart. **sigh** BTW: My temperatures reported have never functioned decently as the resolution of the reports seems to be about 3.0c (5.4F) and makes them unsettable any finer than that and mostly useless. Readings only jump back and forth. I ignore all reading that are not MS related.

Sounds totally confused at this point! LOL From what I can see in your testing, you did some good testing to test the Off time delay (while On cycle is in process) but not the Off time cycle. I still believe they likely all respond the same, according to the many reports here, when they were first launched. These units appear to be fine for an Insteon only system but not as useful as for a home automation controller applying more advanced logic.

No. I am using an Insteon Scene, direct connection, to turn lamps on. Programs determine the brightness level of the lamps in the scene, based on time of day. I am using a program to determine how long the On duration will be and turn the lamps off. The time duration inside the MS II is set to 7 seconds to avoid such long blind times in the MS II. It still remains when using On Only signal mode with the MS II, that the MS II remains completely blind, and unresponsive, during the Off time if motion is detected during the delay that should only affect the On duration. While the MS II is in the Off cycle, it remains blind until no motion is detected for the duration of the On Time setting.

The On cycle time has never been a problem.

OK. It is coming back to me more. I enabled the "send On and Off" and tested the MS II. It works properly and no Off time out causes problems, as you are finding. However the time On delay time does not function according to setting. The closest I could come was the increased delay with motion is about half of the setting delay. Eg. with your 20 second delay, if motion is detected at 18 seconds the resultant "lights off" will result at about 28 seconds. Not that big of a deal but not according to setting implications. The problem starts when you enable "send On" only. I experimented with this last night by increasing my On time to 40 seconds, and found after the lights turn off as long as you keep moving in the room the lights will never turn on again. X seconds of no motion must be detected before the MS II is not blind and will react to motion. This is a bug in the design IMHO. This was never a concern for Insteon (and they appear to have ignored complaints) as the full On and Off signal style works with their Insteon Hub (having no smarts), but smarter response logic from an ISY box require "On only" to retrigger program logic. I dim my brightness levels in the evenings, and sleep hours, as well as, shorten my On times, thus Off signals would just confuse some of this. As a workaround, I use a short On time, so that the Off/ Blind time is not as long.

@IndyMike OK. My MS II, that definitely displays this bad behaviour, is a V.47 R3.4, Date 17 19. As far as I can remember I tested them all for this behaviour and they all do it. So much for not being on the bleeding edge here. Labour dispute just before Insteon collapse? * * * Ohh... The firmware revision (V.47) is from the IoX device page and may not be correct but rather the version UDI supported at the time they wrote the code. * * *

Thanks. I'll have to check those revisions and dates. Mine are all from the old Insteon before my reports were sent. Strange how I always seem to get the versions with the defects. I guess too much "bleeding edge". However I only use one of my three MS IIs as a light operator where this is really annoying. Mine are all on USB power so the frequency of sending ON only isn't important for battery life. A very short On duration creates a very short OFF duration also.

As per other MS devices, and the Insteon MS I, I would expect the MS II to NOT lock itself out and NOT to never report motion, as long as it keeps seeing motion while off. I expect any MS device to report motion as it sees it, and NOT lock off lights until it stops seeing motion. In your example of 20 seconds, after the MS has timed out, and shut off the lights, if you then start walking back and forth, retriggering the OFF timer, it will never turn the lights back on until no motion is seen for at least 20 seconds. I believe you are not seeing the difference between the Off command and the Off duration.

The MS portion uses the same timer for on times and off times. This means once your MS times off it cannot sense motion until the off timer times out. Of course, that never happens as long as the MS keeps sensing motion and lights on and/or detection never happens in a busy room. The only way I have found to make them useful is by using a very short time delay setting, with On only, and let ISY sort out the frequent On signals. I was hoping the new Insteon management would fix this bug as the unit is the best I have found so far. Sent from my SM-S711W using Tapatalk

UDI did a hack to support this model and stated without a proper API, they would no longer do this for any new device. I don't know if the new Insteon ever supplied them with a proper API, but many bugs still exist in the MS II or support drivers. I use them for MS only, and they work reliably most of the time, but with some workarounds in technique from the MS I. Sent from my SM-S711W using Tapatalk

It sounds like Matter will be supported over the ZigBee network anyway. None of this was made clear to me and do much confusion has been spread around everywhere. Sent from my SM-S711W using Tapatalk

OK. I found another OnOff module in my system and it shows exactly the same controls. In the program page lines with XXX On show an option below and percentages of 0% and 100% are options there also. Bug in the IoX system, brought in somewhere in the polISY / eISY conversion of the software?

Middle aged Insteon device. Newer than the ApplianceLinc, but not i3 I don't think?

Well that was my first thought that I confused the device characteristics table. I didn't use the REPLACE function, only the search and replace device name. I deleted the line and replaced it in various ways but it persists. Note my screen shot of the device's page. The header shows the device type while the same page shows the On percentage box. I think I recall an old thread where there was some usefulness to have percentages instead of On/Off but very vague to me now.

First I have noticed this. I just converted a dimmer to an OnOff module (relay contact) because it was making the motor hum. I know this is not recommended but it works for many devices that are not just a motor. Anyway, I noticed that the On commands are now offered a parameter. In this case one is a percentage On. Looking more closely, only 0% and 100% are offered but you can set the OnOff relay module to On @ 0%. Is this an intended thing, or some carry over from so many updates in ISY / IoX bug?

Not quite in this case. It work would the other way around but not when the Door Light status changes to ON status. This is because any device's "switched ON" always evaluates to False, except when the program is invoked by that "Switched ON" line itself. The static status of the Hall Light itself is not relevant, or being tested, in the case of this "switched" construct. Hall Light status is ON would allow the Door Light status changing to on the run Then.

Insteon, and most other, devices are updated by events that happen at the sensing end. For Insteon lightswitches and many other Insteon devices, status is the current status of the electronic dimmer circuit and sends updates when it changes, "control switched" is the current status of the actual switch paddle and sends updates when it changes (pressed). Querying a device asks for the current status of that particular circuit or part and the paddle switch would always send "not pressed" so is not supported with a "status" control. IOW, it is two devices in one box and uses two different styles of update syntaxes to identify which one you want.

This only happened to me (sometimes for months at a time) years back and hasn't happened, to me again, until a few days ago. I figured it was new software installed and would just need rebooting/relinking to "catch up". However it appeared to fail for 4-5 minutes and then finally reconnected.

This doesn't sound correct for these cases. If the subscription failed, how could the Alexa app still show the device's status as operating on and off, but the routine not obeying the status change? The app server knows the status changed so it appears all communications with the portal appear to be functioning properly. This problem is still happening. It just happened to my system again right before my posting about it. I deleted the skill and reinstalled it. However, it took about 5 minutes to reconnect the routines to the status points this time. That delay didn't happen formerly. EDIT: OK. now it makes more sense. My bad! Reading your post again, I believe you are saying there are two different comm channels/methods for this status. One for simple indication and one for Routines.