larryllix

MSIIs are not good for light operations due to not supporting retriggerable signals. They appear to support a retriggerable timer internally, but they do not inform external devices of the retrigger. This doesn;t work for ISY994 and other HA central control systems. Insteon appears to have created this to support the Insteon system devices and defy HA systems. MSIIs have another problem. The internal reset timer is the same internal timer used for the time-on timer (mentioned above). What this means is that once the internal timer expires from lack of motion detected, the MSII cannot send another On signal as long as it detects motion. Whether you require the external retriggered MS signal for HA, or not, you are going to have a period of dark time (no lights on) as long as the same lights on timer is set to. If you continue to move around the room, the lights will never come back on until you stop all motion for the timer time. Complete design fail. ISY is not the only system that will not work nicely with these units. I suspect Insteon doesn't want UDI to survive, and this is just one more clue.

I have not experienced that "insane mode" that I know of but I have seen random garbage come out of one MSII for temperature. The scary part is they are inconsistent between different units and even from one time to the next. Hopefully, MSIIs work with Insteon Hubs, giving hope that UDI will get it figured out one day and we can have at least one Insteon MS we can trust.

What is a "monitor" port?. I only know of two ports on ISY, Ethernet port, and a serial port for the PLM.

I don't use the luminance but I just may use it on one unit now. I am thinking of an algorithm to keep the lighting in my Gathering Room constant. We have some overcast days where the luminance varies greatly in the room and I was going to use outside Tags for that. I have an MS II in that room that is only used for occupancy detection, and not lighting, so it may work well. Now I must try it. Thanks.

I don't think ISY has changed any hardware or bus size. I believe if the old sectoring format would support larger SD card sizes they wouldn't make an SD card that small either. You may note you are not likely to buy anything smaller than a 32GB card now. They stopped making them. Once they got up to the maximum sector size using 2^16bit addressing size sectors, FAT formatting became overloaded and obsolete. Then EXFAT and some other formats were introduced with 32 bits of addressing, so that sector size could back to 256++ bytes, and save HDD space with small files etc. If you format an SSD/HDD using the new formats they seem to work and then the FAT overflows unexpectedly and nobody ever knows why because it worked for the last X years. I think there are some co-ordination problems between the drive size and the FAT table. eg. Y2K = Just need two digits for a year date. Everybody knows it always has "19" in front of it. Now "19" is a bad word. . FAT = file allocation table

Also. I don't think an SD card larger than 32GB can be used in older hardware. The EXFAT and other formats must be used and I doubt ISY would be compatible with it. IIRC 32GB is the largest SD card to still support plain old FAT format without low-level partitioning the SD.

IIRC I think the MS II goes into rapid Insteon packet flooding after a query. I am not sure I have experienced that but found ISY acting very strangely after MS II query. Can't rember the symptoms now. The parameters received were always garbage anyway.

Not likely an actual memory problem inside ISY. I would try turning off you anti-virus software, and/or enlarging your java memory, and reloading your programs again into a new trial of admin console. Check your UI and firmware. They must match. ISY hardware can only support a 2GB SD card. The rest will never be used.

I don't think ISY has the bus size to support more than 2^16 sectors = 2GB of storage. What usually happens in other applications is the O/s overruns the 2GB limitations and then the O/S begins to act crazy. Nothing less than 16GB SD cards are manufactured anymore so......?

You would have to search the forum, just like I would. Look for a Michel Kohanim or my post about the MS II about 6 months ago. Maybe "remove", "discontinue", or "mistake" words.

I have three of them and after testing in key locations, am slowly moving them to non-lighting locations. They seem to work well for just occupancy, and security applications. IMHO they are more reliable for those applications, more compact, and work without batteries. Getting real tired of hearing Insteon is going to launch "we-can't tell-you magic things, please stand-by, because we have a new CEO" every year since 2014, every year when the only thing we have seen is the MS II flop.

The MS II interface was a hack by UDI, as Insteon would not come forth and supply one after years of requesting, and Insteon users had no other source of MSes. Meanwhile, UDI has become frustrated and wanted to remove all support for the messy unit. They didn't after users not having anything else. We were also advised not to rely on any of the side parameters due to lack of accuracy that fluctuates with different usages. My temperatures jump all over the scale with different operations. Do not be surprised if querying the MS II causes your ISY to hang. It does mine at times. Known problem with the ISY/MS II hack. I am thinking of just sending money to China instead of a MIA company. Maybe they will have all the new Insteox products in waiting.

OK. You know the backup has to match the major version revision of the firmware, right? IOW: v4 and v5 backups are not compatible. IIRC UDI changed the style of storage and the internal ISY processing engine in v5 to make it faster and more efficient. Something not quite right what happened to you. If you get even another glitch I would open a ticket with UDI. You may have something overlooked or even a hardware problem, and UDI is better at those things, and more forgiving with hardware problems.

At that point I would factory reset my ISY, reformat the SD card and install ISY v5.0.16C, then restore your v5 backup. This will start your whole thing fresh and forgive all the accumulated junk inside ISY from experimenting. The whole process takes about half an hour or less. You will need to be able to telnet into (PuTTY works) your ISY to format your SD card inside ISY. The reloading of the O/S is built in from a chopped down admin console.

Jumping to v5 will usually find you with some programs an scenes where the code lines could not be upgraded properly and UDI knew it. They will have their program icons marked in yellow, and lines either replaced by comments, or lines in question marked with comments. Some scenes may have to be corrected and re-saved. When done the corrections save a backup in v5 format. They are not compatible. If it gets unbearable, just reload your last v4 and restore from your V4 backup. Allow about 1-4 hours best-worst.

If you made a a good backup, you are never lost with ISY.

No. You need v5!

I would assume so, somewhere but I have never used one.

ISY is not an interactive system, and therefore can't do anything with the failure to respond-on-time, anyway, except to log it in the error log, and possibly not bash the next Ethernet packet out until a response is had or the timeout expires.

@GDavis01Increase your timeout to about 800 mSec. It sounds like you are right on the boundary of the response time, depending on router traffic. @kclenden ISY seems to support SSL encryption, due to offering HTTPS and port:443. I assume that implies the same.

Nice! I would still add something like Wait 2 hours Set light to off to the end of program 1 to cover those contingencies where things get out of sync, as a just-in-case light shut off. It could also be handy if you want the light on for security, You could just open the door once only, and it would time itself off automatically.

IMHO if the door sensing is using "control/switched On" it should avoid oscillation. The control/switched logic test always evaluates as False unless the testing is due to it's own condition change. Lots of Else sections will run but that should not affect the apparent operation. Using status would likely cause oscillation (while the door is open) because you are changing the status of the device inside the same program that is triggering on it.

No. When you disable a program it will stop it (IIRC only at Wait or repeats) but enabling a program doesn't cause any running. I use many second programs that disable and enable the first (one and only one logic) and it would cause problems refiring them if they ran again upon enable. I think most would oscillate then.

Cool idea! My needs have changed on this. I got a new vehicle that the door opens awning style, and I don't control my GDOs. Some people in this neighbourhood never close their GDOs, and if somebody came into the neighbourhood, neighbours would have a complete description, so it isn't much of a problem. Small rural cluster culture.