Bumbershoot

I'm using the 13 bit temp/humidity tags (5), along with the PIR KumoSensors (4) and Water/Moisture sensors (4). All work just fine with the ISY, either with Network Resources or through the nodeserver. BTW, if you're going to buy some of these things, then use this link: https://goo.gl/rXAGk9 @Jimbo, who maintains the Polyglot Wireless Tag nodeserver gets a discount on his purchases when this link is used. Whether you use the nodeserver or not, this is a way show him some support.

I have these in two freezers, one in the garage approx. 70' from the tag manager, and they work very well. I have others in the garden, maybe 150' from the tag manager. I have the tag manager stuck in a cabinet, so the range is likely impaired somewhat by it's location. I use the Wireless Tag nodeserver to put the data into my ISY, which vastly increases the usefulness of these little devices. I have about a dozen of them in my HA environment, using them to help manage irrigation, humidity levels, temperature, occupancy, even to know if anyone has been rooting around in my humidor.

This seems all good. Thanks again for all your excellent work! Looking foreward, I read the .NET Core 3.x is available on FreeBSD. If so, is it possible that NodeLink will have an install script on the Polisy?

The symlink to '/sbin' will have to be owned by 'root', won't it? Back in my sysadmin days, I did everything I could to keep other admins from using the 'root' account when it wasn't necessary. It probably doesn't matter that much on your average RPi, but maybe for consistency (Polyglot installs under the user account, not the 'root' account) the user account might be preferable? Do you know if 'dotnet' and it's supporting files will be included in the standard 'apt' repositories, going forward? I'm imagining that they will, which may make it somewhat more difficult for users to update the file(s) if they're located in a user directory.

Just an FYI: Interestingly, the config file in '/home/pi/node' was created with 'root' ownership/permissions. My usual practice is to keep things in user directories owned by that user, so I changed the ownership of '/home/pi/node/config.xlm' to user 'pi' to give my '/bin/systemctl' control file ('/etc/systemd/system/nodelink.service') permission to run. I could have also just eliminated the 'User=pi' line. [UNIT] Description=NodeLink Server Documentation=http://automationshack.com/nodelink.html Requires=network-online.target After=network-online.target [Service] Type=simple ExecStartPre=/bin/sleep 10 ExecStart=/home/pi/dotnet/dotnet /home/pi/node/NodeLink.dll Restart=always User=pi [Install] WantedBy=multi-user.target

Now that all my devices are working, I get this error in NodeLink related to my RainMachine when the "Enable Weather Node" checkbox is checked: 22019-09-29 07:42:00 - ISY NodeLink Server v0.10.0 started 2019-09-29 07:42:00 - OS: Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux 2019-09-29 07:42:00 - Web config server started (http://192.168.1.5:8090) 2019-09-29 07:42:01 - ISY resolved to 192.168.1.20 (5.0.15A) 2019-09-29 07:42:01 - ISY Node Server config detected (profile 2) 2019-09-29 07:42:04 - Relay Server: Started on port 2405 2019-09-29 07:42:06 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] 2019-09-29 07:42:37 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] 2019-09-29 07:43:07 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] 2019-09-29 07:43:38 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] I don't have a rain sensor attached to my RainMachine, so I suspect this should be normal/expected? This error goes away when the checkbox is unchecked.

Please disregard -- RainMachine is now working as intended on the new NodeLink. Thanks, and sorry for the problem. Network issue here...

This version is way faster to start. Of my devices: Venstar -- appears to connect and populate ISY data as intended WeatherFlow -- appears to connect and populate ISY data as intended Additional ISY Data -- appears to connect and populate the ISY as intended Relay Server -- appears to connect as intended RainMachine -- NodeLink does not connect to RainMachine -- RainMachine IP address and password are correct, and "Use HTTPS" status is correct (unchecked). RainMachine is up and running at the specified IP address, on the specified non-secure port (8081), with specified password. Other than the RainMachine, all appears to be good.

It's still working for me. I haven't changed anything in months in the specific rooms that I use this in, but it was still good as of earlier this morning.

Yes, should be no problem at all. Nowadays, neither. Use the ISY Launcher instead on either or both computers. Using the ISY Launcher may make life easier for you. By using it, you don't have to manually ensure that the ISY UI and firmware versions don't conflict, as the ISY Launcher manages this for you.

+1 for the Eaton. In my professional life, I worked with Eaton gear, and never found issue with it. I read this same article when researching home surge protectors, and installed one of these in my home in 2016. I consider it to be very cheap insurance.

That would be a sketchy marketing scheme, and they'd deserve what they're going to get in the market (oblivion) if they're doing something like that. Then again, for $5.00, maybe so. If you're provoked and persistent, please let us know what you find. Maybe this is a legit deal?

First Alert Hardwired Wireless Smoke Alarm with Photoelectric Sensor and Battery Backup, SA521CN-3ST Amazon has them in stock. I have one, and it works with the Smoke Bridge just fine.

I've read that people are using CAO Wireless Tags in their cars and mailboxes (I don't use them for this purpose, so I can't speak to their effectiveness), and there's a very useful Polyglot nodeserver that makes use of them. The range of these devices is certainly better than bluetooth, so they might provide what you're looking for. They can be used with 4.x.x versions of ISY firmware using network resources, but the nodeserver approach requires ISY 5.x.x firmware and additional hardware to run a nodeserver (usually a Raspberry Pi). I've had good success with these tags when they've been placed in my garden near the end of my driveway (maybe 150' from the tag manager), but I don't know how quickly they handshake with the tag manager when they come back into range, nor do I know how well the signal propagates from a car. Others may have better information.

There are some utilities provided with the lifxlan source code that allows for some mischief with the lights. I figured out that I can use the NodeLink relay server and a network resource on my ISY to call the Python scripts on my RPi. I haven't used them except occasionally, and I don't know how all the effects look. Here's a look at the directory containing the example scripts provided by the lifxlan source code install: pi@raspberrypi:~/src/lifxlan/examples $ ls -alt total 68 drwxr-xr-x 2 pi pi 4096 Feb 23 2018 . -rw-r--r-- 1 pi pi 911 Feb 23 2018 hello_world.py drwxr-xr-x 5 pi pi 4096 Feb 19 2018 .. -rw-r--r-- 1 pi pi 2414 Feb 19 2018 blink_all.py -rw-r--r-- 1 pi pi 2213 Feb 19 2018 blink.py -rw-r--r-- 1 pi pi 2175 Feb 19 2018 breathe_all.py -rwxr-xr-x 1 pi pi 1734 Feb 19 2018 broadcast_color.py -rwxr-xr-x 1 pi pi 136 Feb 19 2018 broadcast_off.py -rwxr-xr-x 1 pi pi 135 Feb 19 2018 broadcast_on.py -rwxr-xr-x 1 pi pi 907 Feb 19 2018 get_color_all.py -rw-r--r-- 1 pi pi 0 Feb 19 2018 __init__.py -rw-r--r-- 1 pi pi 1639 Feb 19 2018 multizone_breathe.py -rw-r--r-- 1 pi pi 2492 Feb 19 2018 multizone_chase.py -rw-r--r-- 1 pi pi 2270 Feb 19 2018 multizone_shimmer.py -rw-r--r-- 1 pi pi 1781 Feb 19 2018 rainbow_all.py -rw-r--r-- 1 pi pi 1815 Feb 19 2018 rainbow.py -rw-r--r-- 1 pi pi 1538 Feb 19 2018 sniffer.py -rw-r--r-- 1 pi pi 986 Feb 19 2018 verbose_lan.py I recall that there's strobe functionality built into the LiFX mobile app, and it appears that people have produced the effect using lifxlan (maybe 'blink.py', or 'multizone_shimmer.py')? You might just be able to comment out the "sleep(1)" statements in 'blink.py' to achieve the affect. You'd have to try that yourself.

I use the LiFX nodeserver to manipulate a light that illuminates an architectural feature in the house that's centrally located. This is to inform occupants of any Elk zones that might be violated. Violating an Elk zone triggers a sequence of three or four programs that run, one of which changes the status of a LiFX bulb. Normally, the light is changed within about a second of the change of state in the Elk zone. This isn't as responsive as an Insteon linked motion sensor turning on a light, but more like a Z-Wave motion sensor turning on a light, maybe slightly slower. Here's a sample program that turns the light to a cyan color: ArtLightCyan - [ID 00BC][Parent 000A][Not Enabled] If 'Devices / dirNodeServers / LiFX / LiFX Controller / LIFX Art Light' Status is 0.0000% And Program 'ArtLightOnHours' is False Then Set 'Devices / dirNodeServers / LiFX / LiFX Controller / LIFX Art Light' On Set 'Devices / dirNodeServers / LiFX / LiFX Controller / LIFX Art Light' Hue 29696 Saturation 65535 Brightness 20000 Color Temp 3500° K in 0 ms Else Set 'Devices / dirNodeServers / LiFX / LiFX Controller / LIFX Art Light' Hue 29696 Saturation 65535 Brightness 20000 Color Temp 3500° K in 0 ms

I didn't expect it to work either, but I tried it after I upgraded to the 500 series dongle and it worked. Needless to say, I was pleased. I'm curious, do all Z-Wave devices on the network need to be plus for this to work, or just all the devices along the route to the ISY?

I don't think that needs to be done with new Z-Wave + (Gen5 or 500 series) boards, which have plug and play network wide inclusion. With the 500 series dongle, I was able to include a Schlage lock securely while in place, probably 60 feet from the ISY (I believe this requires Z-Wave + devices along with the board, though I'm not entirely certain about that). UDI indicated that they're exploring using the newer 700 series Z-Wave in the Polisy. If this works correctly, you'll be able to simply install the device and power it on for inclusion.

@smokegrub, the nodeserver referenced above works very well. My guess is the learning curve to make your CAO Tag data available to your ISY will become far less steep when the Polisy is available. So, in a word, yes.

There is a CAO Wireless Tag nodeserver in the Polyglot Store. https://polyglot.universal-devices.com/ Second from the bottom. It works great, I've been using it for months.

@TomL, I just noticed your question. I do something similar using a routine in Alexa. First, I set a variable in my ISY when a specific person crosses a geofence. I have then exposed that variable as a motion sensor in the Alexa app, and created a routine that announce the persons arrival to a particular Echo in my house. It works. See the first sticky post in this forum for more information:

Yes, good advice. I dim/brighten the LEDs on my switches and KeypadLinks twice a day, and this always seems to always work.

I'm using a RainMachine. It works with the ISY, but not natively. You can interface with it using NodeLink. The RainMachine mostly stands alone in my installation, as it gets hourly forecast updates from local sources and updates the irrigation schedule appropriately. I only use my ISY to augment the RainMachine's irrigation schedule if I've planted new grass or am concerned about new, sensitive plantings on hot days. The beauty of this device is that I've reduced my water consumption 29% annually since I installed it. The RainMachine has it's own, useful mobile application, and it works Alexa, Google Home, etc. The version of MobiLinc I use doesn't properly display any nodes from nodeservers, either NodeLink or Polyglot, so it's not useful in the regard. The only downside to this device that I've found is that it isn't recommended to be installed outdoors.

The Insteon Motion Sensor II has a USB powered option. Otherwise, if you use Z-Wave, the Aeotec Multisensor 6 works very nicely, though it will not turn a light as quickly as an Insteon sensor, as there are no direct links.

Somewhere in the forum there is a post from UDI that indicates there would be no new Insteon devices (such as the siren) for the 4.x.x firmware series (which would mean more releases in the series), so the 5.x.x series is required. Sorry, but I haven't found the specific post...