This is maybe the most bewilderingly difficult thing to find a specification on – the Phoenix pluggable terminal blocks that go to Control4 devices. Good news for you, I can tell you specifically which Phoenix part numbers are required for any HC250, HC800, EA-1, EA-3, EA-5 or IO Extender.
3 position block – Phoenix part 1952270
12 position block – Phoenix part 1701334
Ignore the photos – read the specs. Get a few to keep in stock.
I was lucky enough to get my hands on one of the new Asus PN50 Ryzen 7 boxes yesterday. Fortunately, it has a Ryzen 4700U and should smoke my Pi4 and older Intel 4200U Proxmox box.
The bad is that the Proxmox installer fails and dumps out to a command prompt after obtaining a DHCP lease. While digging through the logs I noticed that the installer was failing trying to start the X server for the GUI. What to do? Run the following:
$ chmod 1777 /tmp
$ apt update
$ apt upgrade
$ Xorg -configure
$ mv /xorg.conf.new /etc/X11/xorg.conf
$ vim /etc/X11/xorg.conf # update Driver "amdgpu"-> "fbdev" <-be sure to get all instances in the case of a multi-head card which tripped me up initially.
$ startxThis should start the Proxmox installer and everything else is smooth sailing. Note, this will not persist through a reboot as this is done within the “live image”, so don’t reboot in this process until Proxmox has completely installed.
EDIT: It seems vim may no longer be part of the installer in 6.3. If vim is not working and you get “Command not found”, try nano instead.
You’ll see elsewhere I was trying to get Aeotec Water Sensor 6s to work with Vera. At the end of the day I gave up. The Aeotecs are much too fiddly and frankly don’t work if you try to do anything with them that isn’t default. So I tried the Fibaro Flood Sensor. I have a Fibaro Motion Sensor that I use to trigger lighting at night via its lux/light sensor and it has been quite good to me.
The Fibaro Flood Sensor has quite a few more features than the Aeotec. It allows out of the box external power instead of battery power. It allows external sensor wires to be connected. It has all the Zwave configuration parameters you could want. The documentation is superior. Also, it works.
Pairing the Fibaro with the Vera was cake. Follow the wizard and it paired no sweat. However, I noticed that the Fibaro showed up in the Vera as an I/O Device instead of a Flood Sensor. Also, the icons were all weird, the Vera didn’t send notifications when water was detected, and the battery status was not being reported. Additionally, the Control4 driver was complaining with the error “device is not a security sensor” when I tried to add the device.
Apparently this is a problem because Fibaro has updated the firmware on the Flood Sensor from v3.2 to v3.3 and the Vera doesn’t know what to do with this. BUT! We have a fix.
Login to the Vera and navigate to Devices > YourDevice > Advanced. On the Params tab update with the following:
device_file: D_FloodSensor1.xml device_type: urn:schemas-micasaverde-com:device:GenericIO:1 with urn:schemas-micasaverde-com:device:FloodSensor:1 manufacturer: Fibaro model: FGFS-101 Gen5 device_json: D_FloodSensorWithTamper1.json category_num = 4 subcategory_num = 2
Now reboot your Vera and you should be in business. A reboot is especially important for the Control4 driver. Until the reboot, the Vera was still reporting the old catergory_num to Control4.
I use a Vera Plus to control my ZWave devices in my home. I also recently purchased a pile of Aeotec ZW122 Water Sensor 6s to put under the dishwasher and near the washer to alert and shut off the water in case of a leak. The Water Sensors weren’t the easiest in the world to configure and hopefully this demystifies the process. Also, a huge shout out to Chris at Aeotec support as he was hugely helpful in figuring this all out.
Firstly, the Water Sensor is what I’ll call an “offline” device. Typically ZWave devices are online all of the time and receive commands from the controller immediately. I have other similar devices, but they wake up on a set timer to receive new configurations. The Water Sensor runs on a battery so it only sends alerts and is never online to receive configuration commands. This is by design to preserve the battery.
One can hold the button on the Water Sensor for 3 seconds to wake up the device to receive configuration commands. When in this mode the LED flashes yellow. HOWEVER, the Vera never sees it to send the command. What to do? In the Vera click Devices > Your Device > Advanced > Commands Tab. Once you put the Water Sensor in the wake state click “Configure Node Now”.
Great, so we can send a command to the device. So what?
There is one fatal flaw to the Water Sensor in my humble opinion – the vibration sensor. The vibration sensor is so ridiculously sensitive that it alerts constantly. These alerts are both audible alarms and “tamper” notifications to your Vera that may show up as push notifications or emails or both depending on how you have your alerts configured. I was getting alerts 50+ times a day as people walked past the dishwasher and the floor vibrated slightly or when the dishwasher itself was running. I even got alerts overnight for no apparent reason. What to do?
First, let’s silence the audible alerts – that is, the constant beeping from the device. This is device option 87 per the engineering sheet and has several options.
1 = water
2 = vibration
4 = tilt
16 = under heat
32 = over heat
The way this works is you add up the values you want active and that is your setting. If you want all audible alerts you would use 1+2+4+16+32=55. In my case, I want an audible alert for water, under heat, and over heat which is 1+16+32=49. If you only want water, you would use 1.
Once this is set, the Vera will tell you it is waiting for the device to wake up. Follow the instructions above to send your configuration. Sometimes this may take a try or two. Great, now the beeping will stop!
This was a bit more work and deep digging. There are two main firmware versions of the Water Sensor – 1.04 and 1.06. I happen to have version 1.06.
If you have version 1.04 you are in some luck. Simply follow the instructions to make the beeping stop. Instead of using parameter 87, use parameter 48.
Version 1.06 is not this easy and is not documented anywhere by Aeotec. Not to get too deep into the ZWave protocol, but there are various classes of commands that one can send. Typically, we only use the “Configuration Command Class”. Version 1.06 has no parameter in the Command Class like parameter 48 in v1.04. What to do? Send raw ZWave commands!
In this case we are going to use the “Notification Command Class” and send raw hex. My fabulous Aeotec engineer sent me this:
0xCC 0xNN 0xNT 0xNS
CC = Command class (0x71)
NN = Set (0x06)
NT = Notification type – Home Security(0x07)
NS = Notification status – disabled (0x00)
Essentially this translates to use the Notification Command Class 0x71, put it in Set mode (0x06), set the home security notification parameter (0x07), set that parameter to disabled (0x00).
How does one do this? Within the Vera navigate to Devices > YourDevice > Settings and note the ID under variable. In my case it was ID71.
Put your Water Sensor into wake up mode per the above instructions. Now navigate to Apps > Develop Apps. You will see a “Test Luup code (Lua)” box. Paste this code into the box, update ‘Node=’ to the variable from above, and click “Go”
luup.call_action('urn:micasaverde-com:serviceId:ZWaveNetwork1','SendData',{Node='71',Data='0x71 0x06 0x07 0x00'},1)
With a little luck you’ll get a SUCCESS notification. Hooray! No more tamper notifications night and day!
WireGuard is a relatively new VPN that is getting a lot of buzz as of late. It is a very simple VPN implementation which makes it very fast and it can run with very little resources on things like phones. Plus, with the rise of COVID and trying to get around certain governmental firewalls, people are suddenly faced with needing to access remote resources more than ever. Additionally, many commercial anonymizing VPN providers support Wireguard as a standard.
Having hung out in various WireGuard forums and sub-reddits, I am finding the same few questions asked over and over and over. This page is an attempt to answer these questions. If you want to know how to install WireGuard, I suggest you see the Arch Wiki WireGuard page or use PiVPN to install WireGuard for the first time. For most people on their first time out, PiVPN can’t be beat.
Table of Contents
Most other VPN implementations people are familiar with such as OpenVPN, Cisco ASA, Palo Alto Global Connect and dozens of others try to solve a lot of problems. They have built in routing, authentication, push compliance policy, and many other features. WireGuard in the most Linux way possible is trying to solve one problem: in-transit encryption. That is, whatever traffic flows between two WireGuard nodes is encrypted.
Also, WireGuard is serverless. That means that all nodes run the same software and you are creating singular point-to-point connections between each node. However, many people do setup WireGuard in a client server style configuration even though technically there is no “server”. In this guide I am assuming you are configuring things up as a typical client-server setup. So please, the pedantic among us, forgive me.
Essentially, WireGuard is an encrypted virtual Ethernet cable and that’s it. What this means is it is up to you to solve many of these other issues.
This is an especially common issue when folks first use PiVPN. Most every network has a router or firewall on it’s edge that connects the LAN to the internet. The router has private IPs on the internal interface and public IPs on the external interface. Typically the issue is that you are trying to connect to your private IP while outside of your network!
If the [Peer] section of your client configuration shows Endpoint = with a value starting with 192.168.x.x, 10.x.x.x, or 172.16.x.x, you are not using the correct IP. While on your LAN, go to ifconfig.me or search for ‘my ip’ on Google. This is the address you should be using.
This assumes you have already confirmed you are trying to connect to the proper external IP. If you are running WireGuard on something other than your router, you must setup a port-forward on your router to the device running WireGuard. Every router and firewall is different, so I can’t possibly tell you how to setup port-forwarding on your router.
This shows a pretty typical port-forwarding setup on my Asus router and pfSense firewall respectively. Hopefully this gives you a hint as to what to look for in your router or firewall.
The key bits of info you must use:
External and internal port – this is 51820 in the default WireGuard configuration.
Protocol – UDP
Internal IP – this is the IP address of your WireGuard server on your internal LAN. This address will start with 192.168.x.x, 10.x.x.x, or 172.16.x.x.
So your Endpoint= value is a proper external IP, you setup a port forward, and it STILL doesn’t work. Verify the WAN IP of your router/firewall. If the WAN IP of your router or firewall starts with 192.168.x.x, 10.x.x.x, or 172.16.x.x you have a double NAT. This means that your ISP has a device blocking public access to your router.
Typically this is fixed by enabling “bridge mode”, “pass through mode” or “modem mode” on the device your ISP has provided. There are countless ISPs and modems that they provide, so I can’t tell you how to fix this. In general, you can point a browser to the IP of the default gateway reported by the WAN interface of your router and sniff around. Google for the make and model of the device your ISP installed along with “bridge mode” and you will likely find others that have solved this issue.
At the end of the day, if the WAN address on the device where you setup the port forward does not match the IP that ifconfig.me tells you, this will never work.
RTNETLINK answers: Operation not supported OR Unable to access interface: Protocol not supportedThis is saying that the WireGuard kernel module is missing. 99.9% of the time this is because your installation never actually completed. Apt may have finished, but you didn’t notice errors in the wireguard-dkms section. This is because your kernel headers either are not installed OR are not the same version as the running kernel. What to do?
On Raspbian
apt update
apt upgrade
apt install raspberrypi-kernel-headers
reboot now
Once the reboot is complete runapt reinstall wireguard-dkms
On Debian/Ubuntu
apt update
apt upgrade
apt install linux-headers-$(uname -r)
reboot now
Once the reboot is complete runapt reinstall wireguard-dkms
If that didn’t work
You likely got yourself on a pre-production kernel somehow. Pre-production kernels often don’t ship with headers. This often happens if you previously ran rpi-update. To fix this run:
sudo apt-get update
sudo apt install --reinstall libraspberrypi0 libraspberrypi-{bin,dev,doc} raspberrypi-bootloader raspberrypi-kernelreboot now
After the reboot, run the commands from the previous section again.
If you have used other VPNs in the past, there is usually a whole menu of parameters relating to encryption type, bit length, Diffie-Hellman Group, etc. In WireGuard, one size fits all. ChaCha20- Poly1305 is the one and only choice. You can read plenty more on the official WireGuard website.