Project Update: No real update here – we just discussed internally about moving forward with a Zigbee and Thread/Matter version, but we’re looking for funding for a Z-Wave version as I know that’s important to a lot of people. More to come.
Ok, well this moved fast – we have officially kicked off this project by paying issuing a PO for the project. I will follow up once we have an official timeline from the manufacturer!
10 Likes
Project Update: The manufacturer has been working on the structure and should have it completed next week. It shares a lot of the same design as our current switches, but we’ve added in a temp/humidity sensor which required a little tweaking.
We have a ways to go due to the backlog of projects, so we won’t be able to start beta testing until July, but it’s great to see them working on the hardware.
5 Likes
Would it be possible for the onf/off switch to get the Fan Timer Display capability that the fan switch has?
I’m thinking about using on/off switch for a bathroom exhaust fan.
@Eric_Inovelli how’s this project going along? Been 3 months since last update.
1 Like
Any chance of an update on the progress for this project?. I’ve spent months trying to figure out a reliable way to get temp/humidity detection in every room in my house and this would be a godsend!
It’s still in the design process. Still alive and well, I think.
Eric may have more details shortly.
Temperature/humidity detection plus a true on/off relay is the perfect combination for a DC bathroom exhaust fan.
1 Like
Project Update: I just got word that they are targeting samples to us on August 20th. They’ve had some delays on this project because we’ve had to put all hands on deck on the Button Controller since there was a last minute problem they were solving for.
Also, there is a change to one of the features of this switch that need to be made in order to satisfy the switch working with all loads and to be a true, “on/off” switch. That change is that we had to sacrifice the ability for the switch to work with a, “dumb” switch in a multi-way setup. Instead, the switch will only be able to work with an Aux switch.
They did some analysis on our prior model and determined there was energy leakage that could impact some loads. I imagine this is why our prior manufacturer told us not to allow the switch to be used on outlets and there were some issues with low voltage lighting and T8 bulbs.
Outside of that, I’m looking forward to receiving the samples in a few weeks!
5 Likes
Thanks for the update @Eric_Inovelli. Quick question: how does this affect the timeline. Is it still sensible to expect the product to be mass produced by end of September?
Makes sense, the gen2 switches leak a lot of current.
I’m here for the Zigbee on/off switch without the buzzing 
2 Likes
Hi @Eric_Inovelli , do you have an update on this project?
1 Like
Copied from the Thread/Matter On/Off version
Hey guys, sorry for the delay – the mmWave stuff has really taken a front seat on the updates from me and I apologize.
A quick update for you:
We were set to get beta samples a month or so ago and at the time, we were having the manufacturer of this switch start looking at an mmWave alternative as the manufacturer working on the mmWave switch (now former manufacturer) was just not working out.
One of the issues the On/Off switch was facing and they wanted to sort out was the temperature sensor and how it was reporting. Long story short, since this switch can control multiple different loads (fan, lights, low-voltage, etc), the temperature reporting was slightly off and they wanted to see if they could work on an algorithm to compensate.
This was sent to me last week:
“We have tested part of the temperature data in the constant temperature and humidity chamber, which is better than the previous test results. We need another week to complete the test and find the calculation method.”
I plan to follow up tonight to see where he’s at. I know he’s got a lot on his plate and was not anticipating handling the mmWave switch, so it kind of threw a wrench in his workload. I think we’re pretty much squared away with what he needs to do with mmWave and the Button Controller, so this switch is now his priority.
Once I hear back from him, I can give a better update with timelines and such. Everything else on the switch has been completed from the hardware side, they just want to get the algorithm for the temperature sensing figured out before sending off the beta units.
4 Likes
Quick update, we received a small batch of beta units (finally). I’m going to install one this weekend and give it a whirl and report back!
Some disappointing news, we will have to scrap the temperature portion for now as they just couldn’t get a reliable way for the algorithm to work properly. We’re keeping the sensor in there in hopes we can create some sort of, “build your own algorithm” type parameter, but for now to keep the project moving, we’ll just move forward with the humidity portion. However, I want to temper expectations here in that the humidity sensor relies on relative heat as well, so we’re not going to be getting exact RH% values. We’re thinking something like low, medium, high detection for now.
Expanding more on the reason why the temperature feature is not going to be promised. They did a ton of testing on various loads and found that the best they could do was to get within a 3-4 degree Celcius (up to 9 degree F) range and to me, that did not seem acceptable as most people (at least speaking from my own experience) monitor within 2-3 degrees Fahrenheit in their houses. If there was a possible 9 degree differential between floors, I would start to wonder what happened to the AC or heater!
What we are thinking about doing is building some sort of algorithm where you can input the type of device you have with as much data as you can (total watts, amps, hp, load type, etc) and it would build an algorithm based on your specific device. Then you can measure that against another sensor or thermostat to see how accurate the algorithm is.
But for the everyday person who is expecting it to work out of the box without fiddling with it, I don’t feel comfortable marketing that feature officially.
7 Likes
I take it this is the case for the Thread version of this switch as well?
This is pretty disappointing as I was hoping to use the on board T/H sensor in bathrooms to automatically kick the exhaust fan on based on humidity as a lot of times I just forget to turn it on when getting into and out of the shower, or I forget to come back after a while of it running to turn it off.
Not a deal breaker tho, I still plan on picking these up and hopefully this will get figured out eventually, in the mean time I’ll just have to use a separate T/H sensor to run workflows with.
Do you know what exactly the issue is? If some super cheap aliexpress sensors can get it down to about 1ºF correct, what is holding them back? Heat the switch itself generates?
1 Like
Yeah there will be a Thread version coming. We’ve already paid for it, but they’re starting with Zigbee first.
Sorry, to be clear, the humidity portion will still work. The sensor itself is a temp+humidity sensor, so we aren’t going to remove it, we’re just not going to market it with temperature until we can figure out a more accurate way to do it.
From a humidity standpoint, the feedback is that since the sensor uses temperature to calculate the value, it can also affect the precise reading of %RH.
However, I think your use-case is exactly what we’re trying to solve for and temperature isn’t as important and IMO, a precise humidity isn’t important either. The sensor just needs to pick up a change in humidity.
Time will tell how accurate it has to be, but this is my opinion right now as I’m testing it with your use-case (I have it in my bathroom too and I am also notorious for not turning on the exhaust fan when I’m in the shower).
Great question – the issue is exactly what you mentioned, which is the heat the actual switch generates. We thought we could offset the internal temperature with an algorithm, but the problem is that there are different types of loads that the switch will be controlling and each load outputs different levels of heat. Here is a screenshot of the data collected from the engineer and their best attempt at an algorithm to offset the ambient and internal temperature difference (note that this is just one of the tests, there’s an entire spreadsheet of values that I didn’t want to bore you with).
What you can see is that we originally thought that as the load wattage increased, so would the temperature difference, so we could easily apply an algorithm to offset the difference based on the wattage. However, if you look at the top portion (VZM30-1 & 2) vs the bottom portion (VZM30-3 & 4), there are different types of loads attached (top is a normal bulb, bottom is an inductive load) and you can see the differences aren’t the same.
So, the issue then becomes, if there are an infinite possibility of loads that can be attached to the switch, these values are impossible to calibrate correctly.
1 Like
I’m thinking that if those values can all be shared with the hub(s), then community members could likely update a driver to perform the calculations with adjustments as needed.
The High/Med/Low would be useful for an automated on/off based on the room’s humidity. However, in cases where the humidity is compared with another room to determine if the fan should be turned on or off, this probably wouldn’t work…
2 Likes
Agree 100%
1 Like
I wonder if there could be a Zigbee command to enable the temperature sensor in its raw form. I could always use another hobby project, so rolling my own logic in Home Assistant to deal with the variability in the sensor might keep me occupied for awhile.
I’m also wondering if accounting for the load on the switch will be even enough if it’s in a box with other switches. It seems like the heat from the other switches in the box would also have to be taken into account.
1 Like