So, I think I'm in a bit of an unusual situation. I work at a camp & retreat center that has wifi throughout. I want to put a few switches in the office that can control outdoor lighting throughout the camp. We currently have switches in each of the buildings, but it is a particularly frustrating job to get all the lights on in the evening when it is brutally cold out or we are short staffed.
Most of our staff is not very tech savvy (my boss literally has his wife print out his emails for him each day!!!) so, I'd love to avoid having to set up any sort of raspberry pi or new phone app.
Is there type of 3-way switch that can connect to the wifi, turn on a light in another building AND turn on an indicator light in the office, without having any sort of wire running between the buildings? Hopefully looking for a simple solution without breaking the bank too.
I greatly appreciate any input that you can give. Thank you!
I have a X10 wall switch system and I want to get rid of it. What would be the easiest transition to something more modern and easy to use with either wifi/homekit capabilities? My current X10 controls 3 zones in my bedroom. All zones are dimmable.
Zone 1 is 4 canister ceiling lights. LED bulbs
Zone 2 is 1 canister ceiling lights. Halogen Bulb
Zone 3 is 1 canister ceiling lights. Halogen Bulb
I have an old plug-in remote from Radio Shack and a wall switch with 3 buttons, each controlling one zone. (images attached)
My wall switch has one two wires from the wall. One black, one white.
Is there any solution easy to install without the need of an electrician? Thanks for any feedback.
Good morning all,
I'm working on weaning myself off of being totally Vera dependent. I've installed MSR on my Fedora home server, and I've been migrating luup Reactor rules over little by little. My hope is to use Vera as a bare bones z-wave hub, until I replace it either with Ezlo (not so sure about), or perhaps Hubitat. I'm just tired of zero new development in Vera, empty promises of native device integration, and cloud services that go down and leave my automation hanging.
In any case, I digress. I've attempted to use Gcal3 on Vera to integrate Public calendars, such as Federal Holidays, School Calendars, etc. It use to somewhat work, but more often than not, all I get from Gcal3 is "token error code: HTTP/1.1 400 Bad Request". The developer no longer is active, and it's effectively not working anymore.
I'd like to use these public calendars as Entity Attributes or Constraints in MSR. For instance, if it's a Federal Holiday, I don't have to work, and I may want to sleep in, which means lights may not come on as early, window coverings in the bedrooms may open later in the day, etc. Similar idea with a school calendar. If "closed" is in the event, my daughter may want to sleep in, and not want the window coverings opened as early.
I'm aware that Ezlo has integration through NuCal to all sorts of web based services, including Google Calendar, but as I stated earlier, I'm undecided on going down that path. Is there anyway to do this on MSR through any of it's abilities, such as HTTP calls or MQTT ( not experienced in MQTT, so I don't know now it works really).
Has anybody already done this?
Thanks for any advice in advance.
Hello all, I am finally ditching my Vera and moving to HA using a Zooz ZST10 Z wave stick. I have around 50 Z wave devices with a good mix of battery devices, locks, sensors and switches. The plan is to include all the AC powered devices first, starting from the ones closest to my Z wave stick then moving outwards. Once that is complete I will go back and include all battery powered devices in the same fashion.
My question is there any quick way to exclude all my Z wave devices from Vera, or should I just delete all devices without excluding them and factory reset each device before pairing to HA?
Some of you may know that I took at shot at building an alternate geofencing solution for Vera. The core of it was system agnostic, using the OwnTracks application and AWS lambdas to track devices and keep a central data, then disseminate that to the Vera via a websocket-based plugin. It worked with other apps as well, including Tasker and GPSLogger, but of the dozen people that were testing it, most used OwnTracks.
A lot was learned in the process, not the least of which is that the success of any such solution is highly dependent on the phone and its settings. Phone manufacturers love to set things up for the longest battery life, of course, but that's usually very anti-geofencing behavior. In the case of at least one brand, it was unusable and the settings could not be modified. It was also cost-prohibitive to maintain on Amazon, as AWS grabs a dime here and a dollar there and before you know it, it added $100/month to my AWS bill, which my wife deducted from my Scotch budget. Unacceptable.
But it's quite reasonable to use OwnTracks to a local endpoint, and I could pretty easily replicate the functionality as a local application, or maybe even as an additional endpoint built into MSR's API (still separate port and process, but in the package).
So the question really is... would you do it, or would you be too concerned about the security risks associated (e.g., dynamic DNS and NAT mapping in the firewall necessary for the phone to contact the service when not on LAN)?
The Debian Linux machine that MSR is running on, has developed an issue and I can no longer login to it via SSH or directly on its terminal.
It was fine earlier this morning I connected to it via WinSCP to copy all the MSR files down for a backup to my laptop.
Then a bit later I could no longer connect to it. Either in WinSCP or Putty SSH, it now says access denied, even though my password is correct.
I then connected a monitor and keyboard up to the Debian box and I cannot login to it directly either, I put in the username and hit enter and I am not given a password prompt to enter it and something I could not read flashes up on the screen very fast and then disappears. I had to record a video and skip through it to capture what is says, see screen capture below.
I tried logging in as user root and my own username same thing happens, it does not even give me a prompt to enter a password.
If I boot the box in to Debian recovery mode instead I am able to login as the root user OK.
Any ideas how to fix this?
Two stores apparently have inventory of RPI 4Bs with 2GB RAM. Get them while they last!Raspberry Pi 4 model B - 2GB - RaspberryStore interadmin12 / 62.95 EUR Raspberry Pi 4 Model B 2GB RAM Raspberry Pi 4 Model B 2GB RAM
Bestel de nieuwe Raspberry Pi 4 B 2GB nu snel en voordelig bij Elektronicavoorjou.nl! - Raspberry Pi Boards, Behuizingen, Heatsinks, Accessoires & meer!
zwave 700 series
I have had a zwave700 dongle to play with for some time and have eventually stopped as its firmware and API was not fully developed for controllers. Back then I was the first one to introduce it to the old place's devs.
Now, looking closer into it, I have come to the same conclusion as this post I have linked above.
Because the main benefits of the 700 series are range and power consumption, I understand now that it mostly benefits client devices and that controllers won't see much of any significant improvement if any. This would explains why silabs didn't really focus on developing a controller sdk/stack for these new chips.
PS: fishwaldo is the author of openzwave and is considered a more than credible expert and authority in zwave.
As you know the new Ezlo product have the 700 series in them. I think the firmware indeed still needs some work as devices that work just fine with a 500 series show some weird behavior on the 700 series, and some 300 device (Everspring door sensor) won't include at all. As I just added a handful of devices to play with this has zero scientific value of course :-).
but maybe a new boost for zwave?
I almost got mine to work back on a vera plus:
And ran into vera similar problem. I had managed to transfer my vera zwave network on it and could actuate some of the devices.
I later found out that indeed the sdk does not have a controller API but only a gateway Z/IP API. Aeotec apparently is also releasing a stick for their controller. It uses a faster chip but the big improvement is on the power management and RF TX pulse strength. Bottom line is that it really has no benefit for a controller because the zwave network bandwidth is limited by RF and the range is really more dependent on the devices and the controller's RX than on the controller.TX. It will be great on battery operated sensors but for a controller it is much ado about nothing. It is really much more about cost reduction than it is about user's benefit. The 700 series chipset is half the price of the 500 series.
So from what you are saying.... They are just at the same point I was at with vera almost 1.5-2 years ago.
I was pretty ignorant back then and was desperately hoping to find a way to fix the vera so I explored using this. I have since learned that zwave was not the problem... Actually it was not the hardware at all.
Black Cat last edited by Black Cat
There is a (very) interesting thread on the HS forum which a few of you may not have read.
Makes me wonder about the 700 series chip as a Controller, but it confirmed my suspicions?
edit: Hope I don't get banned for this......
Interesting, thanks for posting this!
It does confirm the suspicion that the 700 series offers very little benefit for the controller which is why silabs is only now, a couple of years after releasing the chipset, talking about a non Z/IP SDK.
I know that security adds quite a bit of latency to the network and S2 is very significantly faster than S0 but... with 40% of my 170 node network on S0, mostly security sensors, I am not seeing any significant delays so I don't know what Homeseer is doing. 700 series will definitely process the S2 frames faster for the controller but... is it really the bottleneck? I honestly doubt it for most cases.
If security matters most of the benefit will come from moving devices to 700 series chipset with S2 security inclusion.
The key benefit will be on further extending device battery life. The secondary benefit will be from the reduced mesh relay, reducing latencies. You may be interested to know that from my network analysis, the controller signal can almost always reach the furthest devices on the network. It is the return signal which causes the need for middle man devices. It was true for the vera as it is for z-way. It appears that the battery operated devices in particular are set with fairly low TX power which makes the controller look like their RX sensitivity is too low. Bottom line, is 700series on the controller will not extend their range because this is not a problem to begin with... at least not for the vera or the uzb. The range is limited by the devices TX power.
akbooer last edited by
rafale77 last edited by
Yes, there was a couple of thread discussing the boosting of the signal strength using an external antenna mod.
The FCC rule is indeed there because these equipments are certified for interferences and health safety as tested. Such modifications negates their certification. What you don't want to have is a signal which is so strong that it covers over all the other signals in the mesh. I remember having some strange issues with the vera switching zwave light but not knowing that the command succeeded, having to move the vera one centimeter here or one centimeter there to fix the problem. zwave 700 will allow for a stronger signal without antenna mod which again will mostly beneficial when used on the devices. Another illustration of this is my recent report of use of zniffer which enabled me to find out that I was receiving my neighbor's hub's signal without CRC error when I decreased RD noise around my own uzb. He is pretty far away... So don't rush to get a 700series controller. It is a moot upgrade for the most part for which the main benefit could be cost reduction. The technical benefit is in upgrading the devices.