IP Power Strip #07 - Looking at alternatives for the IP Power Strip project

 I have recently discovered the whole Tasmota thing.  It occurred because I finally started setting up some Sonoff switches and Shelly pucks for use with my HA-IOT server.  When I finally pushed the first Tasmota load to a Sonoff switch and set it up as an extension cord.  When I went to Node Red and started controlling the switch, a lot of lights went on in my head.  

Up to this point I have been concentrating on the IP Power Strip as something being controlled by a Raspberry Pi.  Now, I don't need that.  I did however discover that China is going out of their way to prevent the Tasmota from being installed on their products, so OTA changes cannot occur.  They are interested in these products coming under their ecosystem and no other.  I discovered that with a Geeni smart power strip which I was unable to update from an OTA Tasmota push.  I have not at this point, looked into a physical connection with my development system.  I am pretty sure that the initial load onto this device will have had to be done by a physical connection.  I might have to unsolder something to do it.

This change has opened a whole different aspect to getting lights on and off.  I am anxious to get the Shelly pucks to work in my light switches.  As long as I have enough IP address space I should be good.

UPDATE: rejuvinated

The New Input Architecture to my HomeLab

 I think I may have solved my problem with the WiFi system here at the Retirement Community.  As I said before, this is a WiFi only environment; I can run Ethernet but not through the walls and not connected to the WiFi equipment and I have no control over the WiFi system.  The WiFi equipment has two main SSIDs, SSID1 and SSID2 in the following diagram.

The Incoming WiFi Architecture

Notice that there are a number of additional elements to the architecture.  The main input to the MainRouter in my HomeLab is through the WiFi Bridge, a Gl-iNet SLATE router.  That in turn goes into a managed switch, RemoteSwitch, which has a trunk line to my MainSwitch through Two TP-Link AV2000s.  The MainSwitch in turn poses the flow as the [WAN] vlan to the WAN port of my MainRouter.  Having the trunk line between two managed switches gives me great flexibility in how I arrange items in my HomeLab.  In fact I can put part of my [SRV] vlan in the living room where the main input equipment goes.  The MainSwitch also connects to other equipment in my HomeLab as necessary.  Normally I have almost a 30 dBm signal drop between the WiFi Access Point in the living room and my large back bedroom.  This input architecture resolves that.

I have an RPiGateway which is being primed to host input ports into my HomeLab from the outside.  As it turns out I can access RPiGateway from anywhere on the Retirement community campus; I just can't access it from the outside (and I don't need to, I'm not working now).  

Over on the right of the diagram is a problem that was solved through the use of a simple switch.  I have a Sleep-Number bed and it requires a WPA/WPA2 shared key encryption setup on 2.6GHz.  It is also a bit fussy on the level of the signal that it connects to.  So in that respect I have a DIR-505L which is connected to the SSID1 and retransmits a WPA/WPA2 shared key setup to the Sleep-Number bed since WPA/WPA2 is not available from the main WiFi setup.

I have a Tempest Weather station on my balcony which has a hub that was not able to receive the WPA/WPA2 shared key setup from the small bedroom, so it is now connected to a NEWIOTSSID coming from my Unifi AP AC Pro access point.  I also have a SRVSSID broadcast from that access point that I can connect to with my personal laptop in order to perform admin functions on my HomeLab while on my balcony.

I am also using the NEWIOTSSID to connect to a series of Tasmota switches mounted in my HomeLab Rack for the purpose of controlling power to several devices, since I may only have need of a couple at a time.

Turned off the Home Assistant and IOT Server

There were a number of changes I made to the network this week in preparation for the move to Greenspring:

• Took down the RPiPWS and turned off the Tempest weather station.  This is now ready to be packed up.
• I moved the NodeRed docker containers from RPiKodi to an LXC container on my Proxmox server.  I then took down RPiKodi and it is now ready to be packed up.
• I copied the HA-IOT docker containers from the HA-IOT server to an LXC container on my Proxmox server.
• This morning I turned off the HA-IOT server that has been running commanding my lights in the house.  The HA-IOT server and the switch that I was using to send back the data to my router are now ready to be packed up.
• I then spun down the two LXC containers on the Proxmox server since they are no longer needed.
• I removed the hardware IOT equipment from the living room and side room.  These are now ready to be packed up.

All of this seems like loosing an old friend that I have been playing with over these past few years.  But, in hindsight I did learn a lot and now I am ready to take on other challenges.  It will be a few weeks until I am packed and ready to move to Greenspring Village, but at least I will not have these items nagging me in the back of my head.

Tips #10 - Network Setup for Raspberry Pi Static Experiments

After some time working with Raspberry Pis (RPi) I have been able to figure out the kind of network setup that makes sense when you develop over a period of time.  Here are some particulars of what I have found:

• Use of a Managed Switch with a trunk line to all of the vlans in the house saves a lot of running around.
• Use of Tasmota controlled extension cables can give you control of power to the RPis in case there are moments when you only want to concentrate on specific RPis for an experiment
• The managed switch on the desk where you wire up experiments gives you extra network connections when needed.
• The key is to be able to work on just what you want without having other thins on when you don’t need them to be on.

Edgerouter-12 setup for isolated Home-Assistant and IOT vlan

 Here is the cli firewall setup that I decided to use on my Edgerouter-12 (ER-12) to isolate the vlan for my home-assistant and IOT equipment.  This equipment is setup to work within my local network.  You still need a DHCP service defined on the ER-12, unless it comes from an external source.  The basics are:

1. the HA-IOT are allowed to access the internet, they need this to connect to the Wyze servers
2. the HA-IOT can access each other on the vlan
3. the HA-IOT can be accessed by specific laptops located on different vlans
4. the HA-IOT are not allowed to modify configuration on the Edgerouter-12 but can get their DNS and DHCP services from the ER-12
5. the HA-IOT are not allowed to access any other vlan on the ER-12
6. other specific vlans are allowed to access the home-assistant server at the 8123 port (not implemented yet)

First we need a Group of addresses for the RFC-1918 private addresses, control laptops, printer, and the HA-IOT vlan addresses:

set firewall group address-group RFC-1918_GROUP address 192.168.0.0/16
set firewall group address-group RFC-1918_GROUP address 172.16.0.0/12
set firewall group address-group RFC-1918_GROUP address 10.0.0.0/8
set firewall group address-group RFC-1918_GROUP description 'RFC-1918 Group'
set firewall group address-group CONTROL_LAPTOP address <control_laptop_1_IP>
set firewall group address-group CONTROL_LAPTOP address <control_laptop_2_IP>
set firewall group address-group CONTROL_LAPTOP description 'Laptop used for Admin on Network'
set firewall group address-group PRINTER address <printer_IP>
set firewall group address-group PRINTER description 'Printer IP on Network'
set firewall group network-group HA-IOT_GROUP description 'ip addresses in HA-IOT vlan'
set firewall group network-group HA-IOT_GROUP network <HA-IOT_vlan_address_range>/24

Next we need a vif off of switch0 for our vlan:

set interfaces switch switch0 vif <HA-IOT_vlan_tag> address <router_address_on_HA-IOT_vlan>/24
set interfaces switch switch0 vif <HA-IOT_vlan_tag> description HA-IOT
set interfaces switch switch0 vif <HA-IOT_vlan_tag> firewall in name HA-IOT_IN
set interfaces switch switch0 vif <HA-IOT_vlan_tag> firewall local name HA-IOT_LOCAL
set interfaces switch switch0 vif <HA-IOT_vlan_tag> firewall out name HA-IOT_OUT
set interfaces switch switch0 vif <HA-IOT_vlan_tag> ip enable-proxy-arp

The rules for traffic from our HA-IOT vlan to the ER-12 [HA-IOT_IN]:

set firewall name HA-IOT_IN default-action accept
set firewall name HA-IOT_IN description 'Guest In'
set firewall name HA-IOT_IN rule 10 action accept
set firewall name HA-IOT_IN rule 10 description 'accept established and related'
set firewall name HA-IOT_IN rule 10 log disable
set firewall name HA-IOT_IN rule 10 protocol all
set firewall name HA-IOT_IN rule 10 state established enable
set firewall name HA-IOT_IN rule 10 state invalid disable
set firewall name HA-IOT_IN rule 10 state new disable
set firewall name HA-IOT_IN rule 10 state related enable
set firewall name HA-IOT_IN rule 20 action reject
set firewall name HA-IOT_IN rule 20 description 'reject invalid packets'
set firewall name HA-IOT_IN rule 20 log disable
set firewall name HA-IOT_IN rule 20 protocol all
set firewall name HA-IOT_IN rule 20 state established disable
set firewall name HA-IOT_IN rule 20 state invalid enable
set firewall name HA-IOT_IN rule 20 state new disable
set firewall name HA-IOT_IN rule 20 state related disable
set firewall name HA-IOT_IN rule 30 action accept
set firewall name HA-IOT_IN rule 30 description 'allow printer'
set firewall name HA-IOT_IN rule 30 destination group address-group PRINTER
set firewall name HA-IOT_IN rule 30 log disable
set firewall name HA-IOT_IN rule 30 protocol all
set firewall name HA-IOT_IN rule 30 source group address-group CONTROL_LAPTOP
set firewall name HA-IOT_IN rule 40 action accept
set firewall name HA-IOT_IN rule 40 description 'accept HA-IOT traffic'
set firewall name HA-IOT_IN rule 40 destination group network-group HA-IOT_GROUP
set firewall name HA-IOT_IN rule 40 log disable
set firewall name HA-IOT_IN rule 40 protocol all
set firewall name HA-IOT_IN rule 50 action drop
set firewall name HA-IOT_IN rule 50 description 'Block RFC-1918 Traffic'
set firewall name HA-IOT_IN rule 50 destination group address-group RFC-1918_GROUP
set firewall name HA-IOT_IN rule 50 log disable
set firewall name HA-IOT_IN rule 50 protocol all

The rules for traffic from our HA-IOT vlan to the ER-12 itself (DNS, DHCP, other services) [HA-IOT_LOCAL]:

set firewall name HA-IOT_LOCAL default-action drop
set firewall name HA-IOT_LOCAL description 'Guest Local'
set firewall name HA-IOT_LOCAL rule 10 action accept
set firewall name HA-IOT_LOCAL rule 10 description 'accept established and related'
set firewall name HA-IOT_LOCAL rule 10 log disable
set firewall name HA-IOT_LOCAL rule 10 protocol all
set firewall name HA-IOT_LOCAL rule 10 state established enable
set firewall name HA-IOT_LOCAL rule 10 state invalid disable
set firewall name HA-IOT_LOCAL rule 10 state new disable
set firewall name HA-IOT_LOCAL rule 10 state related enable
set firewall name HA-IOT_LOCAL rule 20 action reject
set firewall name HA-IOT_LOCAL rule 20 description 'reject invalid packets'
set firewall name HA-IOT_LOCAL rule 20 log disable
set firewall name HA-IOT_LOCAL rule 20 protocol all
set firewall name HA-IOT_LOCAL rule 20 state established disable
set firewall name HA-IOT_LOCAL rule 20 state invalid enable
set firewall name HA-IOT_LOCAL rule 20 state new disable
set firewall name HA-IOT_LOCAL rule 20 state related disable
set firewall name HA-IOT_LOCAL rule 30 action accept
set firewall name HA-IOT_LOCAL rule 30 description 'Allow DHCP'
set firewall name HA-IOT_LOCAL rule 30 destination port 67
set firewall name HA-IOT_LOCAL rule 30 log disable
set firewall name HA-IOT_LOCAL rule 30 protocol udp
set firewall name HA-IOT_LOCAL rule 30 source port 68
set firewall name HA-IOT_LOCAL rule 40 action accept
set firewall name HA-IOT_LOCAL rule 40 description 'Allow DNS'
set firewall name HA-IOT_LOCAL rule 40 destination port 53
set firewall name HA-IOT_LOCAL rule 40 log disable
set firewall name HA-IOT_LOCAL rule 40 protocol tcp_udp

The rules for traffic from the ER-12 to our HA-IOT vlan [HA-IOT_OUT]:

set firewall name HA-IOT_OUT default-action accept
set firewall name HA-IOT_OUT description 'Guest Out'
set firewall name HA-IOT_OUT rule 10 action accept
set firewall name HA-IOT_OUT rule 10 description 'accept established and related'
set firewall name HA-IOT_OUT rule 10 log disable
set firewall name HA-IOT_OUT rule 10 protocol all
set firewall name HA-IOT_OUT rule 10 state established enable
set firewall name HA-IOT_OUT rule 10 state invalid disable
set firewall name HA-IOT_OUT rule 10 state new disable
set firewall name HA-IOT_OUT rule 10 state related enable
set firewall name HA-IOT_OUT rule 20 action reject
set firewall name HA-IOT_OUT rule 20 description 'reject invalid packets'
set firewall name HA-IOT_OUT rule 20 log disable
set firewall name HA-IOT_OUT rule 20 protocol all
set firewall name HA-IOT_OUT rule 20 state established disable
set firewall name HA-IOT_OUT rule 20 state invalid enable
set firewall name HA-IOT_OUT rule 20 state new disable
set firewall name HA-IOT_OUT rule 20 state related disable
set firewall name HA-IOT_OUT rule 40 action accept
set firewall name HA-IOT_OUT rule 40 description 'accept HA-IOT traffic'
set firewall name HA-IOT_OUT rule 40 log disable
set firewall name HA-IOT_OUT rule 40 protocol all
set firewall name HA-IOT_OUT rule 40 source group network-group HA-IOT_GROUP
set firewall name HA-IOT_OUT rule 50 action drop
set firewall name HA-IOT_OUT rule 50 description 'Drop Non-Guest Traffic'
set firewall name HA-IOT_OUT rule 50 log disable
set firewall name HA-IOT_OUT rule 50 protocol all
set firewall name HA-IOT_OUT rule 50 source group address-group RFC-1918_GROUP

Thinking of making the IOT network self contained

 It occurred to me that at some time in the future, I might have problems with my network again.  But this time I will probably be more dependent on the elements of the network since I am highly dependent on the router providing DHCP IP addresses and the WAP providing the wifi connection for other elements that require support.  I now think it would be wise to be able to isolate my HA-IOT network from the other part of my network, and still be able to have it work if things happen.  Since I use an Atom based computer for the Home-assistant and MQTT base, I might be able to use that to provide both a WAP and a DHCP/DNS server for the network.  If I do that the wifi port can provide connection for the wifi components, the z-wave adapter for the z-wave components, and if the DHCP/DNS server extends to the HA-IOT vlan as it's control, I don't have to depend upon the router to give me those elements.  If I go on a trip, I can cut off everything else and still have the HA-IOT network working as it needs to be.  Since it is on an UPS, it won't be going down anytime soon.  I just have to figure out how to accomplish this on the Atom processor.

Update: over the weekend 1/9 - 10/2021, I modified the HA-IOT vlan to be completely isolated from other vlans, but at the same time able to communicate within the vlan itself.  It is also isolated from modifying the router or any other switch component in the network.  I am also thinking of changing the bandwidth to the internet to something that is below video capability.  My cameras are on a separate vlan which is isolated from everything due to their nature of using an external server.

Unusual problem connecting Node Red to Home-Assistant

I decided to update my IOT network, by updating all of my Docker containers.  In doing so, I encountered an unusual problem with connecting Node Red to my Home-Assistant container.  This was from several containers.  Normally, I would be using the simple username password authentication, but now that authentication mechanism is not working at all.  Interestingly enough, part of the problem shows up with the Node Red extension that connects to HA via websockets.  I can no longer set the Home Assistant server or any of the authentication mechanisms associated with it.  In fact, it now shows up as a simple text box to enter the server's name.  But that does no good because I cannot specify what IP, port, or authentication mechanism that I want to use.  I am not sure of how to fix this issue.

Update (2020-10-08): I put the Node Red container on a Raspberry Pi, completely away from the Home -Assistant container and I was able to get Node Red to connect.  Now I have to figure out what has happened to my Node Red container on the HA-IOT Server.