So, I'm at the 4th Z-wave devices and I still have trouble in getting my Vera operate my door gate, and getting the input from the doorbell. It's already all 220v, because I have an external modulo meant for integration.
So, last night I had an idea: why not use a Shelly 1 as both sensor and opener?
If you need instructions on wiring, here's an image:
Shelly 1 can operate the output independently from the input. So, I prototyped this:I attached to the doorbell sensor O attached to the gate opener
It seems to work on my bench, because I can call the endpoints when the button is pressed or the input is triggered, so I can update virtual devices and execute all the logic I want. I usually integrate these devices with MQTT, but it's not necessary in this case, since I can live with a doorbell buzz being missed.
Bonus point: you can run it at 12v if you want.
Next in my TODO list, the Shelly Universal, a 9 EUR universal binary inputs, with separated inputs and outputs (so, you can get 2 inputs and operate 2 outputs independently), that I'll probably use in my weather sensors project, where I'm using two Shelly 1 at the moment, just the get the inputs.
Shelly i3 is an unbelievably cheap (9,99 EUR/USD) WiFi device that’s part of the fantastic Shelly family. It supports REST API, MQTT and much more.mundzhos Shelly i3 | Shelly Cloud 10
It’s just L,N and 3 inputs. No relays, so it’s a scene controller with bonus point to the fact that you can use your own buttons and keep the aesthetics of your house. Bonus points for WAF. It’s very small, so it will fit in your standard wall box easily.
While I built my own Scene Controller Virtual Device and I’m using MQTT for other devices of the family, Shelly can call your HTTP endpoints on button presses and in this case is more than enough.
Go get it if you need a very cheap, very reliable scene controller for your home.
I'm going to throw this in here, but I don't actually expect a solution, but it might help someone else.
I have three of these magnetic sensors and the work. Kind of.
The issue is that if you open and close the door within about 2 seconds, they trip correctly and then will not untrip unless the door is opened and closed (for more than about 2 seconds) .
This makes them virtually useless for any security application unless you are very slow through the doors.
Even forcing setting 'Tripped' to zero using lua fails. Well it doesn't fail but it's simply reversed:2020-07-03 15:01:24.783 luup_log:0: ALTUI: runLua(luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped", "0", 20780) 2020-07-03 15:01:24.783 luup.variable_set:: 20780.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 1 now: 0 #hooks:0 2020-07-03 15:01:25.044 luup.variable_set:: 20780.urn:micasaverde-com:serviceId:SecuritySensor1.Tripped was: 0 now: 1 #hooks:0
So there it is. Unless anyone has any smart ideas (apart from not opening and closing the doors quickly, I'd avoid buying these.
(PS the only apparent setting that might affect this is the the delay before sending 'untripped' but even setting that to 10 seconds makes no difference. In short, it seems that thee devices have a hardware limitation in how soon they can be tripped.
Is it just me or the GE/Jasco switch or very sensible to power outage ?
Almost each time we have a power outage, I need to replace at least 1 switch to replace.
Each time, same behaviour, the blue led is flashing rapidely and nothing works.
Last power outage, I got 3 switches. 95% of our switch and dimmer are GE/Jasco.
I've just completed my setup (after exactly 3 years from moving in, priorities!) and even if I wrote all the code in C#, I could port it easily to LUA (I guess )
I've used Fully Kiosk Browser + 3D Printed Mount (check https://makesbymike.com/) and a custom HTML dashboard, all running on an Amazon Fire Tablet:
WAF is very high
Sorry for the Italian interface. First row is temperature/humidity sensors (esterno = outside, piscina = pool, salotto = open space, zona giorno = 1st floor, zona notte = 2nd floor, lavanderia = laundry room).
Then I have a bunch of commands/scenes sent to Vera to change blinds/roller shutters (they are automatically managed, but wife pretends to be smarter than code, from time to time ). Last row has notifications for washer/dryer, with the cycle end date. When doing its cycle, the background becomes orange, then green when completed. It's probably the best feature, since the laundry room is in the basement. There's also a link to cams (videosorveglianza) and I automatically open TinyCamPro in case of movement outside/doors/gates are opened.
Is there any interest in a generic wall mount tablet plug-in, offering simple dashboard (maybe json-driven) and integration with Fully Kiosk API?
I'm currently dimming screen on/off, get the battery status and schedule a 20-80 cycle for the battery, via a smart plug and a bunch of lua code. I planned for this when I did the electrical setup, so the tablet has a standard european 503 (recessed) box with ethernet, that I attached to the 5V into the network closet to feed the tablet. I'm updating the screen via AJAX every 30 secs.
Here's a behind the scenes photo as well
I'm in the middle of adding a water tank, because the latest summers were very hot and we had our water restricted, sometimes for weeks and for extended hours during the day (from 7 am to 5 pm).
It should be automatic, thanks to pressure sensors, so it will integrate water when needed (and the main line is open), switch the pump, etc. But I want to add a water level sensor nonetheless, to monitor it if necessary. I will probably just double this project and automate the pool refill as well, since I'm doing it manually at the moment.
I took a look and a lot of people are using Zunos, but I'm not sure I want to spend so much on a so simple system.
Pre-built solutions are OK. Thanks!
I'm in the process of trying to get some info from my pool controller using Modbus. If I'll ever succeed, I want to write a generic plug-in for Vera/openluup, to be added to my collection of virtual device plug-in. I'll write a custom app in a Raspberry offering access to the controller via HTTP.
Long story short, I think I'm almost covered. Typical device:heater pumps (on/off) jets (on/off) lights (dimmers, on/off) filtration (on/off) temperature sensor generic sensor (for ph/redox probes)
I think I'm almost covered by standard devices, but I'm wondering if there's something I'm missing.
I'll probably use a multistring to display status, since it's already supported in mobile apps, but I'm wondering if there's some kind of more granular way to show something and avoid custom devices and similar.
I had this setup and working perfectly in my vera for years. I recently accidentally deleted the device. I tried to re-add it as generic zwave. No problem, all devices come up fine and work. But the vera keeps trying to get secure classes. This is an old device I don’t think it’s zwave plus and it worked on my vera vefore. Vera can’t configure the parameters on the device and vera thinks its a failed device. But it works. Any experts know this one?
With a ChemE and Electrochemist background and wanted to share some understanding on batteries. I looked around and was surprised to find as little as I did on battery comparisons. I only found this site:Disposable Batteries compared -- Alkaline, Lithium, Carbon Zinc, Oxyride
The summary is this:
Alkaline are cheap.
Lithium are expensive but last much longer for high drain applications like powering a motor. They also are much more tolerant to low temperatures so they are more suitable for outdoor use. They have much higher capacity but this difference becomes pretty insignificant when used under low drain condition. (example are z-wave and zigbee sensors) and are therefore both a cost and environmental waste for these applications.
The rechargeable battery technology has progressed a lot in the past 10-15 years. Their biggest drawbacks were low capacity, high self discharge rate and limited number of recharge cycles. All have significantly improved with the LSD (Low Self Discharge) NiMH (Nickel Metal Hydride) batteries. The famous Sanyo/Panasonic eneloop are an example of these.
The use of different batteries will have a significant impact on the battery readback reports from our devices because most of devices estimate the battery capacity percentage based on their voltage assuming they are alkaline:While the alkaline behaves almost linearly draining from 1.55V to 1.1V, lithium present a near step function characteristic starting at ~1.75V (AA -LR6 and AAA-LR3) and stay at that voltage until suddenly dropping to 1.5V at which point they are almost incapable of delivering high currents. They will then deliver gradually lower currents until ~1.4V where they can be considered empty. NiMH on the other hand start at ~1.35V and drop near linearly to 1.1V
The result is that lithium batteries will always show as full until suddenly stopping to work, showing 0% or nothing at all.
NiMH will start at 0-25% when full. These all can render the battery read-back very misleading... But either alternative choices according their applications will be much more cost effective and environmentally savvy.
Adding info on other common rechargeable batteries for those interested but less relevant for Smarthomes:
NiCd: Still found in many devices, they have much smaller energy density (lower capacity) and support fewer recharge cycles than NiMH. They offer the advantage of having a very short load transient, meaning they are able to deliver full current immediately after the load is put on them, making them very good for powering motors. They are mostly used in power tools
Li-Ion: Very high energy density. It is what is used in laptops, phones and... some planes. More expensive and not available in low voltage/small format.
Sharing links I often use to explain z-wave:Understanding Z-Wave Networks, Nodes & Devices
Z-Wave technology enables you to create a reliable home automation network with numerous nodes and devices communicating with each other simultaneously.Your Guide to a User Friendly & Stable Z-Wave Network
This guide looks deeper into Z-Wave controllers and networks, enabling you to achieve a user friendly and stable Z-Wave network in your home.
I am seeing a lot reports and complains throughout various home automation forums about people complaining about failed flash:
SD cards (notoriously rPis and all SBCs for every known platforms)
USB drives (vera USB logging)
and internal on board flash for vera.
All of these cause system failures and data corruption. While the vera is a case of needless auto-flagellation with their very highly rated SLC NAND flash paired with a mind boggling drive partitioning causing them to barely use 10% of the storage space the hardware makes available, the others are due to using inappropriate hardware for their purpose.
What is important to know is that a flash memory cell has a limited lifetime.
The smaller the cell is, the thinner the gate holding the charge is and the more fragile/less enduring it is. This is why the industry has gone vertical with V-NAND or 3D NAND instead of just shrinking the size of the cells to reduce cost and increase density.
Following this move to the third dimension, came the idea that each charge could contain more than one bit by holding different state values. That's what MLC (Multi Level Cell, in practice only 2) and TLC (Tri Level Cell) and now QLC (Quad Level Cell). MLC means that the cell now has 4 states (2^2), TLC has 8 (2^3), QLC has 16 (2^4) states or distinct cell voltage levels. The compromise to these multi-level of the cells is increased error rate and lower reliability (accuracy of the charge depends in part on how worn the gate is) which needs to be compensated by ECC in their controllers. It is indeed harder to get the voltage right than a digital have voltage or have not logic. The difference in endurance can be a couple of orders of magnitude! The cheaper NAND flash like what you find in eMMC, SD cards and most USB flash drives are slow and have less write endurance because of they use the cheaper QLC/TLC technologies. (1GB QLC costs the same to make as 256MB of SLC and possibly significantly less because of smaller cell size)
Another layer of reliability improvements in SSDs has been TRIM, garbage collection, and wear leveling. All three features are meant to distribute the writing more evenly across the cells, run background reset of the cells so as to speed up the write process...
Well none of these exist on a controller-less NAND like an SD card or eMMC and this is why you could have a large flash drive corrupt data because it's been overwriting the exact same cells over and over while the rest of the cells may never have been used.
For a home automation platform which needs to constantly save variable states and logs in various files, an SSD is definitely a better way to go than those controller-less storages... This is even more true for embedded/non replaceable storage...
Many of us have done this before but this is meant for the newbies. This solves the problem some people may have to get their home automation radios centered in their mesh in the house while their server would be somewhere else.
It is inspired by what Homeseer has done with their Z-NET product which is a raspberry pi with a zwave HAT which uses ser2net to send its zwave serial port over IP to the host controller but it is really more generically useable across any type of platform controller or even radio. Regardless of it being zwave or zigbee or even bluetooth if this ever takes off, they all are serial ports on the operating system. Since they all use a distribution of linux, one can install ser2net on it.
I posted the nuke-vera script which adds the disabling of everything vera on a vera plus.
This example from the openhab forum is for a rPiOct 7, 2017 Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide
Hi, Recently i’ve been working on virtualising all IT systems in my home. I’ve virtualised my NAS, Firewall, Router, Network Video Recorder and ofcourse my Openhab2 setup. During this virtualisation effort i ran into a few issues with regards to passing through my Z-wave.me USB1 z-wave dongle to...
This is a more generic exampleConnecting to a Remote Serial Port over TCP/IP
It is a well known trick but very useful.
Fibaro RGBW Controller 2
DesT last edited by
Anyone used this device to control LED strip ?
@dest I have two of the older version "RGBW Controller".
One is driving a white LED strip on one of the channels and a set of 12V lights on the other channel.
The second unit is driving one white LED strip on one of the channels and three sets of LED spots on the other three channels.
In other words no RGB(W) strips on any of them.
To be honest these two Fibaro units have caused the most headache of all my units. Strange behaviour activating/deactivating other zwave devices a few times, not reporting status etc. I have had to unpair them a few times over the years. They seem a bit better on Zway, but not faultless there either.
Fibaro devices seem have problems with compatibility, because of this I have decided not to buy any more.
DesT last edited by
@ArcherS Got the new version and having a hard time to understand how to connect my RGB strip on it without any "switch".
Just connected from the power source than controlling the RGB...
@dest You connect the constant 12/24V power supply + to P and - to GND on the Fibaro. Also connect + on the PSU to + on the LED strip.
Then you connect the OUTnn to the corresponding pins on the RBG LED strip.
If you do not want any switches INnn on the Fibaro should unconnected.
My three (not four as I wrote above, sorry) set of LEDs in the kitchen are connected according to this diagram, perhaps it can be of some use. Note that the LED strip in my case is a white one that only requires one "OUT" connection to the Fibaro.
Also note that on the older Fibaro version that I have "OUTnn" were named R, G, B and W.
The diagram is in Swedish, but I hope it makes sense anyway.