MWareman

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!

That’s probably a symptom of the device you are controlling not telling ISY that the device has changed state (as it was put to market before the patent that protected the idea expired). Before the patent expired, devices used various workarounds and not all of the workarounds work anymore. Best way is probably to modify your spoken to drive a program in ISY (instead of the device directly) and have the program turn the fan on or off. That way (since the ISY is controlling the fan) it will update the status.

Unfortunately, one of the limitations (of Ring) is that you cannot directly get an image from the camera. There is a functionality request formerly submitted to their team to add this functionality - but it's not there yet. I have a separate Foscam that looks out the sidelight of my front door. This resource I reference is a network resource that calls a .php script on my internal server. This .php script obtains a snapshot from the Foscam camera and sends it as an attachment to my Pushover account.

On Windows machines, you can add a secondary IP address to the network stack - so your computer can communicate on either IP network. Then, use the old IP to access the ISY with the Admin Console, then logon and Change the IP of ISY.

That almost always causes issues. If you have not disabled the 3am “Query All”, you will get the state reversing at this time. This is because trigger reverse causes notifications from the sensor triggering to be reversed, but the answer to a query will not be reversed. Of course, you can disable the 3am query. But then devices can get out of sync and will not get get synced up until the device is triggered.

The Ring devices that use the hub were purchased by Rng and use a different protocol. They modified things to have them work with the same app but likely work very differently to the Ring native spotlights and floodlights that don’t need the hub. How to they show up in the PGC log?

That’s awesome. Especially if a javascript function can be pushed down to th google home devices to process spoken commands locally and make relevant api calls directly to the ISY. That way, if the Internet connection goes down the Google Home integrations will still function - at least those driving ISY devices, scenes and programs.