larryllix

First, scenes responders do not send out any acknowledgements. Only program commands get ACKed, so there is no way to even know if they were successful. or the device even exists. Is another device sends out a new scene no monitoring would know about it without a distinct new query for status. Scenes were only ever meant to be a one way comm. I don't use them hardly at all, anymore. However most of my lights are WiFi bulbs. There is likely a complex way the PLM could tell ISY when a device has been fiddled with but it was never implemented due to too many errors that could occur.

If really needed I would write a program to detect several devices' ranges and consider True as the scene being activated. My method would be to define a state variable with a program that detects the variable to be non-zero and controls the scene with that. Now you can detect the state of the variable and turn it on and off via the variable. Of course this doesn't work for controls done outside of your ISY box. The program mentioned above would though. Remember levels are not always reported as exact numbers so a range of detection is required fir each device. Sent from my SM-S711W using Tapatalk

Possible coincidence with your schedules correcting it just after you press the button?

Ohhh one more thought. My original single AX92u seemed to have weird problems during summer hot days. Even though it was in a A/C controlled home. Placing a Tag on top of it I found problems when it showed over 45c. Many routers I have had had poor ventilation convection paths and mounting them vertically on a wall solved that. Now I have USB plugged muffin fans underneath each piece.

Well that was one thing that made me really happy with Insteon. It was it's own network, own protocol, and not dependent on WiFi or a router. That gave me power to power cycle my router using a simple OnOff plug-in module. My thoughts were when all devices were initially sent a "get your free IP address", at the same time, some devices just lost out. I could never prove that but it seemed a select few devices took turns not getting an IP address. My worst was my ISY, while I was in the Carribean, contained an assigned IP address of 00:00:00 and the router didn't like that one. It scrambled my whole network until I rebooted the router and then my ISY. I had three ASUS AC5100 s (can't remember the model number now AX92U?) and the vendor rebuilt one (after tearing my hair out for a year and a half) seemed to work better, the older one short of NVRAM went into a background, low usage, position, and the third was always a problem until I moved, and went back to a single router, without a crippled WiFi Tx power again. They never state the maximum devices they can handle in the device table, only the count per band. With your only 14, that shouldn't ever exceed and limits. It would likely be extremely hard to recreate it but you could try power blinking both devices at the same time for 1/2 second. Nahhh..too much work, unless it happens again! Good luck

I found rebooting the router would correct things mostly. I suspected my older router had too little NVRAM inside and couldn't remember that many connects. The magic number for that router seemed to be around 51 devices. Later versions had more NVRAM installed.

I had a lot of problems (using an advanced ASUS mesh router system) in years gone by with problems like this. Not sure how your electrical grid operates in your area but many use Reclosing schemes, to minimise the area that gets affected with lightning strikes. The basic idea is, when there is lightning on a transmission line and it arcs to the earth, the ionised pathway conducts the grid energy behind it, and can cause much more system damage. Generalised: the reclosing scheme detects this and trips the line out, with an almost instant reclose (picks the line back up). This breaks the lightning discharge arc and allows the ionised air / wood pathway to dissipate so the grid energy doesn't follow. This usually followed by longer and longer delays coupled with "toughened" sensing, to detect whether it worked and/or there may be a pole down and a tree branch laying on the line. Techniques vary by area and system needs, and Engineers ideas. /lesson done What this means to my routers was that a sudden and fast blink of the AC was enough to scramble some of the router and device(s) logic but not long enough to make the router see the power supply blink and it wouldn't reboot going through a cold start-up process issuing invites to all the devices to relink to the router. My solution to that was to build an algorythm for ISY to see some "all the way through the system and back" packet detection and cause a series of increasing length power blinks for my router equipment. IIRC I used a web timeclock for proof of passthrough system and a second algorithm on some local device along with a query to detect at two levels. I found these routers would just forget some devices were allowed to talk through to the Internet at times. Everything but one device worked fine but one just couldn't talk through, despite everything inside the router showing as perfect. Anyway, I installed counters for occurrences and almost all my problems went away on that front. The counters proved it was still happening but could be automatically corrected. My conclusion was that different devices had different time lengths before cold booting. It may be worth investigating. I know you are a tech aggressive guy.

I don't understand why you want to turn the fan off first. This adds more chances to glitch the control with elctrical spikes causing damage to the circuits,

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