vbPhil

I have our bathroom light’s On Level set to 25%. So it comes on dim all the time. If you want full brightness you double tap the switch. Been working this way for years. Seems to fit our logic okay. We have several other lights set same way.

Tag type 32, Moisture Sensor has a Wet State parameter which I believe to be driver GV12. This driver only updates on a change so at restart it comes up as WET, whether it is or not. I discovered this when the power on Polisy was cycled, and then the node indicated WET. Well, this kicked off an ISY Program and started up a water pump. Any ideas on how to circumvent this behavior? I prefer it would come up correctly indicating whether it was DRY or WET.

Ok, thanks. I see Polisy in my network map as a LAN connection which makes sense because it's plugged in. Can't remember if I gave it that name or not, but I don't see any wireless connection. It is reserved in DHCP. I'll try unplugging the network cable and restart Polisy to see if that wakes up the WiFi. Edit: that was a bust. Polisy wouldn't come online without the network cable plugged in. I'm leaving well enough alone. I don't need the WiFi right now anyway. don't want to break anything.

I've never used that style before but it's interesting. I gave it a try and it is working for me in IoP.

I had looked for it in PG3 but couldn't find anything. What would it show up as in my network map if it was connected to the router? I would think there would be some way to check on it's settings using SSH.

Where is the setup or configuration for it checked or entered?

?

@upstatemike just curious why 2.4 GHz is bad. I'm considering ZigBee as an Insteon replacement, that or z-wave.

Was wondering if it's okay to take off the WiFi antennas on the Polisy Pro? I thought they might be interfering with the Z-Wave dongle and WiFi doesn't work anyway.

I haven't needed a dedicated repeater. Several devices already near the Controller so all is working fine, installations are all unique. The z-wave dongle gets the best range when it's vertical so use a right-angle USB adapter if necessary. Here's what I used: Posdou USB 3.0 Male to Female 90 Degree Right Angle Extension Adapter, USB Upward and Downward Connector

I've added 4 z-wave devices instead of expanding Insteon and they're all at one end of the house where the controller is. So, no problems. I'm not sure I'm set on switching entirely to z-wave yet, still wondering about ZigBee.

I bought mine from The Smartesthouse.com thesmartesthouse

Your assumption looks correct to me, but you never know what evil lurks. Another technique that I use is with 2 programs; one is the trigger and the other the control. The trigger program contains your IF statement and then calls the control program. The control program has no IF statements. In the body it immediately disables the trigger program, does what it needs to and then re-enables the trigger program. I've never had a problem using WAIT in the control program this way. I use this with a WirelessTag moisture sensor to detect a water level and it was notorious with successive false triggers around the event.

Thanks for all the info here. Adding node servers just for an occasional need to write an entry into the ISY Log is a bit overkill. Maybe someday when ISY programming grows up there'll be a function intrinsic to the ISY language to write to the log. For now, I'll just use an Insteon Device, something unused but installed, as a marker, send it a command and find that in the log.

@MrBillI've seen some mention of "Virtual Node Servers" in the forums. I figured you might know what they are. Where is there more information on what and how to do? Perhaps I can do something with that to produce an ISY Log entry from a Program.

@MrBillNot sure what nodelink is. As a workaround I added a command to an unused Insteon or X-10 device and then search for that in the log. At least it helps troubleshooting to see when the program is running and what else is happening at the same time. So, it's good to have it all in the ISY log.

My working Polisy runs barely warm to the touch on top. I measured it at around 105 F.

The ISY Program Summary is fine, but it only shows the last time a program runs. Is there a way for a program to write an entry to the ISY Log file that would identify the program name or some unique identifier?

@JimboAutomates I cleared the ISY log and then downloaded it after about 10 minutes. Please take a look and notice all of the "Custom Control XX" messages, especially Custom Control 14. I don't know what they are for. They're being written for each of the tags every minute. In the Tag Manager I have my Tag Updates set for every 10 minutes. So I guess I'm expecting to see a tag's data every 10 minutes. ISY Log.v5.4.3__Fri 2022.04.15 12.32.42.txt

I understand. I guess it’s meant to be as it is. I need to keep the tag monitoring frequent, in many cases like every 5 or 10 minutes. I can see the log file getting ever larger as more NS are added. How big can the log file grow? Does it keep appending and discarding older entries? I can see a case where older, less frequent entries could go unseen do to faster data filling the log.

I was using the ISY log file, the one downloaded from the Admin Console's Tool Menu (in case there's more than one) to troubleshoot some Insteon Device problems and I noticed the log is overwhelmed with entries from the WirelessTag NS and my 12 Tags. Just wondering if we could rethink why and is it necessary to have all that in the log, or maybe some way to control it. My log file has 148,207 lines. The WirelessTag entries are 137,372 lines. So, 93% of the log file is from the WirelessTag NS. Just seems a bit much when thrown in with the occasional Insteon traffic.

The variables are not based on Insteon events. This is the code for one of them. I'm running the Serial PLM. To explain more. This program is scheduled to run at 11:59 and is enabled. It kicks off 3 other program that each increment their own variable.

Yes I agree that Polisy/Polyglot/IoP might still need some hardening. I have a small isy utility program that increments a few variables every night a 11:59. It's been running error free for many years. Last night it didn't increment any of the variables. Nothing in the logs that I can see except that at 11:59 there was activity between the PG3 WirelessTag Node Server and ISY. I'll keep an eye on this for anything else that I might notice. Of note, I ran the program manually before checking the ISY program summary readout so I can't say if the program actually ran last night like it should have.

The PLM is required for Insteon. Polisy requires a Z-Wave controller USB plugin. Zooz 700 has been tested with it and it's what I'm using.

I've been following this scenario, that I gleaned from various forum posts, for quite awhile and it has served me well. When the upgrade executes it determines what packages you need and in the order it will use. Before answering yes just look through what was written to the display to see what it will do. You can always answer no if you're just wondering what it would do. Upgrading all services There are 5 important services that have to run: polyglot (and pg3), udx (does sys admin stuff), isy (IoP), and mongod (will be gone when pg3 is official). So, pkg update and upgrade upgrades all packages. The services restart the aforementioned. You should include isy. sudo service polyglot stop sudo service udx stop sudo pkg update sudo pkg upgrade sudo service polyglot start sudo service udx start sudo service isy start sudo service pg3 restart