larryllix

Are they both still freeBSD O/S?

Agreed. See you again in another years when somebody raises the need again.

Yeah I got it working eventually. However, that technique does not indicate the status of a scene. It only indicates the last scene command scene command sent out from ISY for the scene it is embedded into. Changing any component device inside the scene via another scene command or device control does not affect it's status despite the scene's resultant statuses not being true anymore. Again, people are attempting to assign a status to a trigger signal. It isn't really possible as they are different types of Insteon elements and not relatable to each other.

I saw no definitions or instructions to add any keys or values to it. That may be the problem??

I don't consider a state variable used for conversion into a pseudodevice as useful in an Insteon Scene. I find no way to incorporate these variables, or the pseudodevices the ISY Portal converts them into, even seen inside ISY at this point. Maybe I missed something there? However, it was mentioned about the Virtual device PG3 node server, that appears to be able to perform as a pseudodevices inside ISY, can be inserted into an Insteon Scene, and has intrigued me. I have installed the Virtual node server into my PG3 and it shows up inside ISY via IoX, but I cannot get it to perform anything except read one parameter that is permanently set to "True". I can drop it into an Insteon Scene and it appears as a valid device but never changes to show anything except "True", whatever parameter that is supposed to represent.

I am confused. Your original post showed it basically correct. Your program was sunset+30 minutes. Now you are complaining about sunset-30 minutes and it not operating today? I offered an explanation for the 2 minute calc error but now you are saying it didn't operate one evening but it did the next it did? Perhaps listen to some of the experienced helpers here, that have given advise, think about it, and respond to them. i see no problems except your story appears to be changing about what the problem is.

It may have been slow to come (as most UDI improvements) but the pseudodevice was an improvement made by UDI after much discussion over the years. Perhaps they just don't brag enough when they produce updates? However, it still doesn't solve all the scene monitoring possibilities that I can foresee. Now you have me interested to experiment with the technique (now that I am aware of it). I do not use many Insteon Scenes anymore, now that my lighting is almost all WiFi, ISY programs, and three MS IIs with buggy firmware in them.

I am not sure either of these techniques will work for many situations though. If I add a spare device or a pseudo device to a scene and turn it on, and then rest the level of one (or more) device(s) with another scene with the monitoring techniques actually see the original scene is not in effect anymore? With the spare Insteon device, I know it will into indicate properly, but with the pseudo device inside ISY, who knows how many smarts they put into it?

Sunset and sunrise change by about 2 minutes every day of the year except peak winter and peak summer.

Does this "virtual" respond to external devices initiating a scene, say from a Switchlinc dimmer button press? That was always one of the problems with attempting to detect the status of a current Insteon scene. Perhaps another Switchlinc sends out a different Insteon scene command that modifies one of the devices to a different level? I believe these reasons may be why a status flag has never been successful to detect whether a scene is still intact. They are not binary statuses with just True and False....sort of.

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.

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.

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?