Cloud-less communication with EG (door sensor)

If you have a question or need help, this is the place to be.
Post Reply
skribb
Experienced User
Posts: 228
Joined: Thu Feb 12, 2015 7:22 pm
Location: Win7 64bit

Cloud-less communication with EG (door sensor)

Post by skribb » Fri Aug 24, 2018 6:55 pm

Sorry about the rather cryptic thread title.

My issue is this:

I have a door sensor that I need to be able to talk to EG without connecting via the internet first.

¤ I tried Tellstick Duo - unreliable (it receives a different signal from the door sensor each time and so is practically unusable - Telldus support told me it's normal that the Tellstick receives different signals from the door sensor, even if i use a Telldus door sensor... go figure...)

¤ I tried RFXtrx - unreliable (EG plugin hogs 25% of my CPU, and the COM-port seems to re-assign at random, making the connection very unreliable)


I am now using....
an Aeotec Gen5 door sensor (z-wave plus)....
...which talks to a SmartThings hub....
...which connects to the internet in order to talk to a wall mounted android tablet...
...which then sends a (LAN-only) UDP datagram to EG using the Tasker app (Tasker picks up the notification received in the Smartthings app).

I DO NOT want a simple device like a door sensor to need an internet connection and such a loooong chain of commands/devices, to tell my PC that the door is open/closed!! If my internet connection goes down, the security facet is out the window! (one could argue that a power outage would render a security system completely irrelevant, however; a UPS would easily solve that bottleneck)

if I buy an Aeotec Z-Stick Gen5 and use the new Z-wave plugin for EG, will I be able to receive signals from the door sensor into EG directly, using only Z-wave/Z-wave plus? ------- Can anyone confirm that this setup is actually a viable option? Viable in this case meaning "cloudless, and not requiring extensive hair-pulling"

Huge thanks.
Automation is life.

Win7 64bit
EG: v0.5.0-rc4

User avatar
kgschlosser
Site Admin
Posts: 5494
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Cloud-less communication with EG (door sensor)

Post by kgschlosser » Fri Aug 24, 2018 9:16 pm

yes The ZWave is point to point. no middle men.

But... and there is always a but.. ZWave is a Mesh Network and every device that is hard wired is a repeater. if you do not have a network that has enough connections or ways for data to get from the device to the controller and vice versa a device could be busy doing something else and if it is asked to repeat a packet it will not be able to. This will typically only happen on large networks where sections of the network are a good distance away from another section. or if you have a single device that is within range of only one device. This does not happen all that often and it is also user solvable by adding additional devices or a repeater.

I have personally found that the Z-Wave network protocol and network topology to be extremely reliable. what has not been is the software that tells the controller what to do. That is why i have spent so much time getting a native control into EG for ZWave. One of the biggest goals i have when writing any type of software that communicates with a local device is to not have it need a middle man or any kind of a cloud service. I want EG to talk directly to the device and the device to talk directly to EG. This is what the ZWave plugin does.


The issue with the com ports I am not sure exactly what the issue is there. I do know that with windows if you move a device from one USB port to another Windows will install a whole new set of drivers and issue a new com port to that device. even tho it is the same device. I have made some concessions to handle this so that if you do move the USB port you can go into the plugin config and assign the new comport the same network name as the old com port and everything will resume as it was. I have been trying to locate some kind of a unique identifier that i can use to track the device. one that I can use without the need to actually connect with the device first. like a serial number that i can get from WMI or some other Windows device API. I have not been able to locate anything like that as of yet. I am however still working on it. I am sure I will locate something and this will make everything automatic. but for the present setup if the comport of the zstick does change you will have to go and set the network name the new comport. It's an inconvenience but at least you do not have to setup the whole network again.

I would steer clear of anything that uses WiFi because of the inherent instability of WiFi and the crappy access points that are made for the home consumer. Plus for every device that is connected to WiFi the bandwidth to each device gets smaller and smaller. it reserves the bandwidth for a device even if said device is not using it. so the more WiFi devices you have attached to a single AP the slow it will becomes for every single device. even if the actual WiFi traffic has not increased a huge amount.

I have quite a few ZWave devices and have never had an issue with the network. or devices disappearing. I have had lots of issues with the software that controls everything not working properly. Since I changed everything over to using the ZWave plugin I have not had a single issue. No crashes. Every command gets to where it needs to. the devices are getting polled properly and in a manner that the responses are extremely quick. I am talking 10's of milliseconds for an event to get fired in EG that something has changed. Not the several seconds or not at all sort of thing that was happening with other solutions.

I have every light in my house on my ZWave network. as well as a few security sensors and fan controllers. I am working on getting my landscape lighting controller added to the network still. The landscape lighting controller is a ZWave controller it's self so it sets up a bit differently then a simple on/off switch. I think that I have more devices then the usual user and this would make for slower polling times. But because of the Admin panel I made you have so much control over the network you can actually control what variables on a specific device to poll for. so if there are variable changes that occur on a device that you do not care about you can turn off the polling for that specific variable. That is a HUGE + to help keeping an optimized network.

One of the things that I have strived for is really quick events for any changes made. If EG is going to be a viable HA solution having an event get triggered 3 seconds after something has changed is simply not good enough. having an alarm sensor get get triggered and not knowing that this has happened for 3 seconds is a really long time. If you have a light you want to turn on when a motion sensor is triggered 3 seconds could mean falling down the stairs.

and as a note. The battery backup thing is exactly what I did. I took a 5000 watt 240 volt APC UPS, worked some magic on it. I added a 240 to 120 step down also made by APC and I wired the thing into my house. I picked up 4 batteries that are 14" tall 4.5" wide and 27" long. These are purpose built batteries so they can fit into a 19" server rack. each weighs in at close to 200 LBS are a sealed AGM battery (safe to use indoors under limited ventilation) I rewired the UPS to accommodate these new batteries as an external attachment, It is able to supply power to every light in my house and a limited number of outlets and the fans on my gas fireplaces as well as all of my computers/hubs/routers/monitors and my projector in my media room. if every single thing that is attached is turned on it can supply power for 8 hours. on average electric use it will run for 24 hours. this is nice because i can run my generator during the day and at night i do not have to run it.

battery backup 350.00 ebay
step down - 100.00 ebay
4 batteries - 200.00 local battery recycling place. (UPS batteries get changed out by companies even if they are good. I got batteries that had 10 years left to their original warranty and were also from the same lot)
all other miscellaneous things 300.00
number of time i got electrocuted - to many to count

all of the costs listed above is very little to pay for peace of mind.


I am the one that made the ZWave plugin and I can confirm without any doubt that this is the exact data path to a device


EG ---> Z-Stick ----> devices
devices ---> Z-Stick ----> EG
If you like the work I have been doing then feel free to Image

skribb
Experienced User
Posts: 228
Joined: Thu Feb 12, 2015 7:22 pm
Location: Win7 64bit

Re: Cloud-less communication with EG (door sensor)

Post by skribb » Sat Aug 25, 2018 12:23 am

kgschlosser wrote:
Fri Aug 24, 2018 9:16 pm

But... and there is always a but.. ZWave is a Mesh Network and every device that is hard wired is a repeater. if you do not have a network that has enough connections or ways for data to get from the device to the controller and vice versa a device could be busy doing something else and if it is asked to repeat a packet it will not be able to. This will typically only happen on large networks where sections of the network are a good distance away from another section. or if you have a single device that is within range of only one device. This does not happen all that often and it is also user solvable by adding additional devices or a repeater.
I live in a small apartment, so i don't think this is applicable to my situation.
I want EG to talk directly to the device and the device to talk directly to EG. This is what the ZWave plugin does.
Sounds very promising.

The issue with the com ports I am not sure exactly what the issue is there.
Me neither, but that's for another thread. In conjunction with the constant 25% CPU usage, I can't be bothered troubleshooting the RFXtrx stuff. A story for another time. :roll:
I would steer clear of anything that uses WiFi because of the inherent instability of WiFi and the crappy access points that are made for the home consumer. Plus for every device that is connected to WiFi the bandwidth to each device gets smaller and smaller. it reserves the bandwidth for a device even if said device is not using it. so the more WiFi devices you have attached to a single AP the slow it will becomes for every single device. even if the actual WiFi traffic has not increased a huge amount.
Hmm, this i did not know. I don't think i've had any issues of this nature thus far, however. Again, small apartment... few devices.. :D
I am talking 10's of milliseconds for an event to get fired in EG that something has changed. Not the several seconds or not at all sort of thing that was happening with other solutions.

Good to know!

EG ---> Z-Stick ----> devices
devices ---> Z-Stick ----> EG
I presume the Aeotec Gen5 Z-stick will work with the Aeotec Gen5 door sensor.
I'll be throwing money your way if the z-wave plugin meets my demands. :mrgreen:

EDIT: Aeotec Z-Stick Gen5 ordered.
Automation is life.

Win7 64bit
EG: v0.5.0-rc4

User avatar
kgschlosser
Site Admin
Posts: 5494
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Cloud-less communication with EG (door sensor)

Post by kgschlosser » Sat Aug 25, 2018 3:44 am

well i am sure you will be opening up your wallet. I know this for a fact. The plugin is plane Jane. there are no "frills" you will be using 2 actions. Get and Set. there are 2 more actions but those are strictly for dimmable switches.

You have the ability to access every single bit of a device. everything it has to offer. The nice thing is that when device manufacturers step outside the bounds of the typical Z-Wave protocol and offer custom settings for a device. The plugin has the ability to add those custom settings. as an example. changing the way a switch works. so if some ding dong installs the thing upside down it can be corrected with this plugin. no need to remove the switch from the wall. So long as the switch manufacturer offers a custom setting to change this.

I can make specific actions for all the various devices. like door locks. and lights and window coverings. I may do this in order to remove the complexity of using a devices native variable name, which sometimes may not make any sense.
If you like the work I have been doing then feel free to Image

Post Reply