MWareman

In my case - I had Darksky, Push and Ring in PGC (slots 2,3,6 respectively). These all show in my Polisy in the same slots (as unmanaged). Like you - expected. I also have ISYLink in slot 25. That also shows correctly in Polisy. I do have WeatherflowPGC in slot 2 on PGC. However - on Policy slot 2 shows "Solaredge" as unmanaged. That's new (I don't have a SolarEdge). There does not appear to be any way to get rid of it as Polisy is not the master for the poly. I just tried adding WeatherflowPoly again - same error 128 from the 'git clone'. I tried the MQTT poly just in case - same. Error 128.

‘Unmanaged’ are when Polyglot detects ISY slots have a Poly in them, but it’s not managed by this instance. This could be another Polyglot install - or PolyglotCloud. In my case, I had the expected unmanaged polys from PolyglotCloud. That being said, I also gained the SolarEdge poly. No idea where that one came from.

Hmm... cannot seem to add any nodeservers. When I try to add one - nothing shows up in /var/polyglot/nodeservers Permissions of the folder look right. But the clone of the repo did not work: 2019-10-26 12:00:05 - error: NSChild: WeatherFlowPoly cloneRepo: Non-zero exit code: 128 2019-10-26 12:00:05 - error: NSResponse: Success: false - cloneRepo: Non-zero exit code: 128 2019-10-26 12:01:53 - error: NS: Error getting server.json required fields. name and executable are required. - Error: ENOENT: no such file or directory, open '/var/polyglot/nodeservers/WeatherFlowPoly/server.json' Another one: 2019-10-26 12:06:07 - error: NSChild: WirelessTag cloneRepo: Non-zero exit code: 128 2019-10-26 12:06:07 - error: NSResponse: Success: false - cloneRepo: Non-zero exit code: 128

NRs are faster because they are essentially real-time. Email uses store-and-forward queuing. Additionally - Pushover (and others) popup on mobile devices notification system - while email may or may not. Overall - the triggered activity => eyeball time is way faster with Pushover, Pushbullet, others as compared to email. As I mentioned above though - the way ISY processes substitutions in email and NRs is very different. Some substitutions are not supported in NRs (in particular the # substitution to represent the triggering device) because NRs are not processed synchronously on ISY - so by the time ISY performs the substitution it does not know which device triggered it.

Also in the wiki is documentation on substitution variables... https://wiki.universal-devices.com/index.php?title=ISY-994i_Series:EMail_and_Networking_Substitution_Variables Date and time will be problematic for network rules - as to comply with URL requirements certain characters must be URL encoded - and ISY itself does URL encoding in the admin console as NRs are saved (rather than at runtime). So, time and date substitutions will not normally succeed in network rules.

Changing the 'admin' password in the Polisy GUI does not change it at the OS level. I don't know if that's intentional though - but you probably should have a way to address that. Otherwise - all Polisy users are gong to have a known admin credential open to local SSH. I'm only sending a single DNS service to my LAN devices - but POLISY is trying to use Google's DNS service by default (the local DNS host is third on the list). Is it safe to modify /etc/resolv.conf? [edit: Nope. This get's re-written each reboot] I also noted that 'reboot' still needs the admin sudu password. For a client device like this - the user probably shouldn't have to 'sudo' to issue a 'reboot'. I see that the polyglot user home directory is "/var/polyglot" - but the polyglot instruction is not quite accurate for the placement of the .env file. Instructions say "~polyglot\.polyglot\.env" but the actual placement on Polisy is "~polyglot\.env" I set the custom SSL variable and place my SSL certificate into /var/polyglot\ssl\custom - after a restart it's using my own SSL cert. Polyglot *really* should implement a UI for doing this... (and, as mentioned before - consider LetsEncrypt as an option!)

Got my Polisy! Woot! Here is my initial feedback.. https://polisy:3000 did not work. But then - I have a relatively secure network at home - most discovery protocols are somewhat crippled so this did not surprise me. I watched my DHCP log and saw it used the hostname 'polisy' to obtain an IP address. Nice touch. I connected by IP to https://x.x.x.x:3000 - and after accepting the self-signed cert and authenticating I was in. Suggestions: Perhaps an initial config wizard. Instead of having a default password - lead the user thru setting one on first use. Branding is needed for sure. I have 3 ISYs on my network. It seemed to discover one after each other. In reality - when it sees more than one there should be a list to choose from. I entered my ISY credentials and it connected just fine. It came with Polyglot 2.2.1 - and is offering 2.2.3. Since this is a known hardware platform - Polyglot should recognize it as such. Text like this is somewhat superfluous: However, the upgrade is failing with: The reboot menu has "Restart ISY" - "Restart Polyglot" but no "Restart Polisy" Finally - there really should be a way to allow the end user to set a DNS name of the device and register for a LetsEncrypt certificate to replace the self-signed cert initially deployed. Once registered - it should auto-renew. One thing that's immediately obvious - this thing is extremely fast and lean. Congratulations to the whole UDI team! I'm really looking forward to what the future will bring with this device.

I’m going to have to measure mine now. My neighbors are going to wonder what’s going on! I think it’s more of an attenuation issue (since it’s likely grounded) that a standing wave issue overloading the device. Switching the mailbox out to a plastic one is probably the best action - but I’m still hopeful that I can mount a tag of some kind outside the mailbox and have a regular door sensor to detect mailbox opening. CAO don’t make such a tag that I know of though.

Yes, I have. I have 4 in cold boxes (two freezers, a fridge and a fridge drawer) all working without issue. Just cannot get a signal from within my mailbox...

Let us know if you get it to work in your mailbox... I cannot get a signal from mine in our mailbox - after all it’s a low power radio and placed in what amounts to a faraday cage... I still have a project ahead of me to figure a more reliable solution for this one...

Interesting. How are these wired? In theory - you could wire a couple of Aeotec mini on/off devices to give multiple speeds as well. An expensive way to do this - but likely more reliable than the Fanlinc.

You are indeed ‘stuck’ with PGC for Ring - because Ring needs the server hosting the poly to be accessible to their API with a trusted certificate on a static URL. To host on a local device (like Polisy) - everyone would have to contact Ring to get their own API key and register a URL for their callbacks. This is not really possible for most people.

Well, there are Python and node.js binding for the API. Someone that knows nodeservers could likely implement fairly easily. Biggest issues are ISY lack of string handling (workarounds are in the Polyglot world - but it sure would be nice to see strings natively as ISY variables!) and being able to keep track of costs (there is a free tier - and many would want to stay within that).

Well - physics says that wires will melt when the high current causes the conductor to heat - melting the insulator (possibly causing a short, spark and possible fire) and (ultimately) the conductor itself (causing a break). This takes time. The material in the wire cannot heat instantly. Fortunately, surges from most events like lightning are just too darn quick to allow such heating to generally occur. I suspect that the rated wire used in this example can in fact handle this - especially since it's the manufacturer that stated so.

Just more FUD and non-truth. This was NOT stated at all. Please cease from making such statement without any basis in truth. to remind you what I actually posted: This was a ridiculous small gauge of wire stated as an example of a connection less than the 10' which passed your stated directive (many time) of "less than 10 feet" without providing any guidance yourself on gauges acceptable. Witness: Another example where you imply that only length has any implication for impedance. Another lie: Yet another - this time a true statement - again omitting the need to ensure wire gauge is large enough: The first example where you claim that as long as it's less than 10 feet - the connection is fine: You then go on to suggest that gauge of wire has no effect on final impedance by claiming it's irrelevant to the discussion. It is not. you you rightly state - the NEC has a lot to say about minimum wire gauges for this purpose - yet you have repeatedly only posted the 10' distance figure with zero advise on wire gauge - something that's very dangerous to do to a non-professional electrician who may well just visit the local home depot and buy the cheapest wire found thinking is satisfies the need. To assert my point clearly. Length absolutely affects impedance (shorter wire = lower impedance for a given wire gauge). However - so does wire gauge (smaller AWG number = bigger wire = lower impedance for a given wire length). The two are related. 10' max for this purpose is sound advise for sure. but you need to also specify a minimum gauge as well.

And I feel that this is the issue here. You have sent this thread well away from what the OP asked about. Keeping threads on-topic is what will help OPs learn. Trying to 'bludgeon' others to learn beyond what they are asking about by taking a thread on a tangent is not the best way to approach this. If you feel you have something to share about primary lightning protection (and it's clear you do - though I wouldn't rely on links to posts Reddit that you authored yourself) - may I suggest you start your own thread about it. I'm sure there is a lot we can agree on with regards to primary lightning protection. This is a subject of value to this community - it deserves it's own thread.

LOL. I had a whole response typed out - reread it - and then decided to delete it. Sometimes, some things are best left unsaid.

Impedance is not defined (solely) by distance as a certain poster implies - nor has it been stated what impedance is acceptable for a correct ground able to withstand lightning level surges. A 22 gauge wire at 10’ will not do what’s being claimed - but a much large gauge will work fine out to much more than 10’. The idea of anything within 10’ is OK is a false (maybe not entirely false - but certainly misleading) statement. For protecting against surges - you also have to consider induced surges in wires running parallel to the path to earth. That’s not mentioned either. FUD is also being added. OP asked about surge protectors. Not direct-strike lightning protection. Completely different risks. The latter is much harder (and much more expensive) to protect against. Buying insurance is likely a cheaper option for the average homeowner. For a TV Station, phone company etc - protecting against the direct strike is paramount. Personally, I’ll do my own extensive research and not waste cycles on unsolicited partial information such as posted here...

I've never performed "File/restore devices" myself - and handled this device-by-device the one time I had to do it. This allowed me to handle the many battery devices more gracefully. As I said - you have to put each battery device into linking mode first. This requires a visit to each battery device and hitting it's button - then the restore must be initiated before linking mode times out. You cannot go around the place putting all devices into linking mode before the first devices timeout so a global restore is never going to work in this scenario.

Right-click each switch, sensor, light, device (etc) and select 'Restore'. If it's a battery device - it will have to be put into linking mode first.

It sounds like you may have started a second restore PLM before completing the first restore PLM operation. It’s important to follow the process completely and ensure all devices are updated! (No 101010 icons) after the restore was started. Yes, but that will write half of each link - and not likely fix the underlying issue. There are two records of each link. One in the PLM per device it’s linked to (letting the PLM know the address of each device it’s linked to) and one in every other device on your Insteon network (letting it know the address of the PLM). If you changed your PLM - you can write your PLM config many times and it won’t change that your devices still don’t know the new PLM address - so the links will stay broken until all devices have a record of the new PLM address. Your devices are probably still sending their updates to the old PLM address - causing all your programs to fail (no triggering events are being received). Restoring all devices other than the PLM should restore the other side of the link to those devices.

And to expand a little on what Larryllix said... If you were to add other triggering conditions to the If clause - then when that triggering condition occurs outside of the timebox, the Else will execute. Within the time-box, then either Then or Else will execute based on the logic of the other triggering condition you added to the If clause. Adding a Wait complicates things as well - the Wait will be terminated if any triggering condition in the If changes.

Have you written the new PLM to all your devices yet? They may still be trying to communicate to your old (dead) PLM. Try a ‘Restore Device’ On one affected device - and if that solves it you will need to go around each individual device and restore it.

By ‘running on the ISY’ (and by saying you are using the REST API) - can I assume that you have the ‘Host’ field set to the actual IP address of the ISY in the network resources (and not 127.0.0.1 or localhost). Using any kind of loopback interface has been known to cause deadlocks and crashes in ISY - and that could be the cause of your issues.

Another thing to bear in mind (this has caught many out). The Elk network interface can only accept a single client. If you have a connection open from your phone, ISY will not be able to connect. Make sure ALL other clients of the Elk are disconnected!