Whitehambone

@larryllix Well, from the perspective of an FCC-licensed Amateur Radio operator, 2 inches for the 900 Mhz band is not much. Typically the minimum usable antenna length is a ¼ wavelength of a giving frequency or at 900 Mhz, roughly 3.25 inches. Anything less than ¼ wave usually has or is basically a load coil and is a sacrifice in performance. Antenna gain is generally compared to ½ wave dipole that is 13 inches long at this frequency. Now some computer-generated compact antenna designs produce gain, but it is a moot point. The 902 Mhz to 928 Mhz band is allocated to the Amateur Radio service. The Z-Wave dongle is a part-15 device in this band and has limited emissions requirements. Typically the emission requirements are measured in microvolts per meter, a combination of power (watts) and antenna gain. So, in short, you are correct; it doesn’t matter if the antenna is 2 inches. There is some reading more boring than my post on the FFC’s website regarding part-15 devices.

I bought the Zooz 700 Series Z-Wave Plus S2 months ago when I saw many other brands were not in stock. I figured I would take a chance that Polisy would support it someday. My luck appears to be good for a change. ?

He mentioned the lights are not responding timely as well. Did you look at the event viewer to see if there is something going on?

@jellis, take a look at this post. I was stuck on 12.0 as well. I think I also did this:

Read this post and the one above, perhaps it will help. I ran this to update to FreeBSD polisy 13.0-RELEASE-p4: sudo pkg install -f FreeBSD-kernel-polisy

@Michel Kohanim, I notice the error log is difficult to read, like there is no line break (or carriage return, as some of us may know them by). I read there were some logging issues in the earlier posts. Maybe I missed mention of this? ISY Error Log.v5.0.4__Thu 2021.08.26 12.57.34 PM.txt

I came to the party a little late. I followed the various post and I am running ISY on Polisy. There must have been some updates as it reports ISY version 5.0.4_28. Going to do some testing soon. Thanks for your hard work UDI !

I have a ton of Insteon devices and only a few Z wave devices. I was going to try these once I needed to replace a switch. But nothing has failed yet. I am also curious on what others plan to use. https://www.casetawireless.com/products/dimmers-switches

Here is @Michel Kohanim post that @gviliunas was referring:

I am glad to hear about the progress and can't wait to try it out! Thanks UDI team for your work. I hope when released it will include the ability to support the Node Server developers.

@Michel Kohanim, please correct me if I am wrong, but here is how I see this. The questionable future of UDI's Polisy integration with Insteon is NOT UDI's fault, it is Insteon's. Insteon has not defined a path to the future. Current Insteon products will be support through Polisy directly, or worse case, from Polisy through the ISY. Future Insteon products may or may not be supported (if they even have any future products). I had seen another post on UDI's Forum that seemed to imply that Insteon future is questionable at best. I had hoped Insteon's limited product availability was only due to the COVID shutdowns. https://forum.universal-devices.com/topic/31292-insteon-being-discontinued/

Installed with no issues and Z-Wave devices are reporting.

I have not used variables for counting, but it seem like it should work great. Just increment up the variable every time the IOLinc is triggered. Then run a program to stop and reset everything when you get to the desired number. I found this post that counts heat and cool cycles. https://forum.universal-devices.com/topic/14719-t5800t5900-hvac-humidity-cycle-and-runtime-programs/

@ewind. I don't think the ISY fully supports the Insteon Siren. I think the best you can do for a chime is make it Beep at the highest level (255).

@kck I am getting this error: File "/usr/lib/python3.7/urllib/request.py", line 569, in error return self._call_chain(*args) File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain result = func(*args) File "/usr/lib/python3.7/urllib/request.py", line 649, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 404: Not Found root@raspberrypi:/boot# Exiting pisetup due to error in getinstallinfo Any suggestions? Is this a compatibility issue with my screen?

@vspete, I forgot to mention that I found much better HTTPS performance offloading SSL to PC running Stunnle. It really shortens the delay to the ISY.

Upgraded without issues and Z-Wave devices are reporting as normal.

It seemed I had some similar troubles when I updated my Fortigate from 6.2.X to 6.4.X with UDP/TCP bombardment. That why I was wonder what FortiOS you were running. I had to do some creative networking to resolve the problem, but I never figured what caused my issues. Most people don't run FortiGate's at home. But I still get similar things as you are experiencing in my logs and I also use MobiLinc. I uninstalled MobiLinc on my AppleWatch and will see what happens.

What FortiOS are you running? Have you upgraded the Fortigate's firmware recently? I have experienced many of these same issues.

@someguy Do you have a Polisy, run Polyglot or MobiLinc? There are some alternative alert methods.

I have experienced this as well with LED Christmas Lights and LampLinc. To make them work, I plugged in a small incandescent bulb, like a 4 watt night light. Either use a T-adapter or plug it into the end of the string of lights. It kind of defeats the energy savings purpose of the LED lights, but it made them work pretty well. Even dimming worked for me with this method.

I have found better performance offloading the SSL encryption to Stunnel on a PC. If you find slow connections to the ISY using HTTPS, consider this option.

Not everyone uses or wants to use the product as intended. So I would like the auto or switch reset to be a user-programmable option. Why not give us both possibilities? For instance, I used one of the older leak sensors for detecting when a sump pump could not keep up with the rain load. I mounted the sensor on a piece of wood and soldered remote sensing wires to the sensor's circuit board (twin-lead wire). I suspended the wire about 1/2 inch above the floor. If the sump pump could not keep up, the leak sensor would start another pump and send an alert. When the water fell under the remote contacts, the leak sensor would reset automatically, and after a programmed time, the pump would turn off. I could remotely watch the situation on a camera and take additional action if necessary. It worked great, but it would not work with the new style sensor. Of course, I used this setup until I could correctly repair the problem, which required a lot of digging. Not fun.

If you find the thread, please post a link here. I have not heard of this issue and would like to know more about it.

Open a support ticket, I am sure they can get it straighten out for you.