Why I’m not worried about Skynet destroying humanity in my lifetime

In my new role as field applications engineer for Silicon Labs I use virtually every video conferencing app available. What irks me is that none of them can figure out which microphone to use. If the largest corporations in the world with thousands of smart engineers can’t solve this simple problem then I think it’s safe to assume that the singularity is a long way off.

Sorry for posting off the Z-Wave topic but this is truly ridiculous. My job involves supporting customers all over the US and I often call the Z-Wave home office in Denmark. Using a video conferencing app is essential, not so much for the video but to be able to share screens for presentations or demos. I normally use the app my customer prefers so I’ve used all of the popular ones in the last few weeks. Skype, WebEx, Google Hangouts, Zoom, GoToMeeting. bluejeans and the SiLabs corporate solution Lifesize.

Can you hear me?

The start of every call begins with “can you hear me?”. Then various members of the call attempt to get their microphone and speakers to work. After a couple of minutes a few members invariably call into the dial up number and then we can finally get down to business.

I acknowledge the problem isn’t trivial. My laptop has a built in mic, speakers, a line in/out, my docking port has line in/out, my monitor has speakers, I have 2 USB headsets and a Bluetooth one. So there are a lot of possible microphones and speakers.

How hard can it be?

Some apps are better than others. Most give you a menu to change the audio and quickly test the audio before the call starts. Some make reasonable guesses but still get it wrong occasionally. Skype for business is the worst as it gives a limited set of choices because Microsoft “knows” which audio to use but unfortunately is just wrong with no way to pick the correct one. ugh.

Seems to me there is a simple solution – at the start of the call, if the input currently selected has nothing on it but one of the others does, switch to the one with sound!Or at least popup a menu suggesting the user might want to switch to the input with the user yelling “can you hear me” into the mic.

If a few engineers can’t solve this simple problem then I feel we have some time before Skynet becomes self aware and decides to wipe us all out.

Z-Wave Summit Fall 2018 Philadelphia

The Z-Wave Summit is usually held only once each year in the USA and it is not to be missed. I’ll give a brief overview of what was discussed at the summit in the short post below. But if you didn’t attend in person, you missed the most valuable aspect of the summit which is the chance to meet and talk to other Z-Wave developers. This year the summit was hosted by Bulogics in the city of brotherly love,  Philadelphia PA. Bulogics is a Z-Wave certification house so they know everything about Z-Wave and how to have a good time!

2018ZWaveSummitMitch.jpg

Summit Notes

The 700 series was officially “revealed” at the summit with many presentations talking about the new ARM based Z-Wave transceiver. The summit has over 140 attendees from 70 companies not including all the Silicon Labs and Alliance employees. This is the largest attendance of a summit to date and reflects the rapidly growing world of Z-Wave.

Matt Johnson, IoT Sr. VP, described the roadmap for multiprotocol chips which include Z-Wave, zigbee, BLE and Wifi as well as proprietary protocols. For the immediate term though the focus is on getting the 700 series shipping. The real key for Z-Wave is the interoperability and certification ensuring every Z-Wave device can communicate with every other device.

Z-Wave product manager Johan Pedersen presented the important improvements in the 700 series over the 500 series:

  • ARM M4 32-bit CPU
  • 150% RF range improvement in the US and more in EU/Asia
  • Lower power and faster wakeup time making coin cell operation a reality
  • Lower cost due to elimination of the external NVM & SAW
  • Single HW build for all regions due to elimination of the SAW filter
  • Longer battery life with 1.8-3.6V operation
  • Serial debugging

By far my main interest as a developer is that we finally have a real CPU with an M4 and serial debugging so I can finally single step my code and figure out where I went wrong!

The next natural question of course is when will the 700 series be a reality? The answer is “soon”. Ugh. Developers kits are supposed to be available soon and the parts will be shipping in early 2019.

Technical Track

On the second day of the summit the groups are split between marketing and technical geeks like me. More presentations on things like the new Z-Wave Plus V2 requirements which will go into effect with the 700 series release. The V2 requirements significantly ups the bar for support for various command classes with the goal of making Z-Wave devices to fully inform the hub of their capabilities. There should be little or no custom coding to support most V2 devices – the device will tell you everything it can do.

The presentation by Alex Capecelatro, founder of Josh.ai, described the future of voice control which sounds amazing. Alex described just how hard voice control really is and has a long way to go before it really works the way we all want it to. I liked his quote from the New York Times: “We overestimate what technology can do in 3 years but underestimate what can be done in 10 years”. Z-Wave has come a long way in the dozen years it’s been around.

Configuration Command Class

2018summitERI gave a presentation on Configuration Command Class Version 4 and all the wonderful things it can do. The most notable point is that 2/3rds of the Z-Wave Plus certified devices have at least one Configuration Parameter. Yet many hubs have no way of modifying or displaying to the user the current value of parameters. Z-Wave Plus V2 mandates support for Configuration Command Class V4 for both hubs and devices so you need to get busy! My presentation title is: “The Chicken vs Egg is over: Moving Your Product to Configuration Version 4” which can be downloaded from this link: Z-WaveAlliance2018EricRyherd.

Interoperables Band

Once again the band The Interoperables played at the evening get together at a local brewery. These guys are really good for having only practiced a couple of times!

2018ZWaveSummitInteroperables

DrZWave joins Silicon Labs

That’s right, I have officially joined Silicon Labs as an FAE covering the Eastern US. I can be contacted at drzwave@Silabs.com.

 

 

 

 

8051 8-bit CPU Coding Tricks & Tips

The death of the 8-bit CPU has been prognosticated for over a decade but these old tiny workhorses keep going and going and going. Z-Wave is currently based on the venerable Intel 8051 CPU but we’re about to get an upgrade to a 32-bit ARM CPU via the 700 series which is due out later this year. In this posting I’ll give a few tips on coding in C for the 8051 to typically improve speed of execution.

I’ve been writing code for 8-bit CPUs since the 1980s and I designed a few in the 1990s. I also designed a couple of 32-bit RISC CPUs in the 1990s and early 2000s. I often had to squeeze the code just a little harder to get an operation to happen just fast enough to meet a system requirement. This meant that I either had to code in assembly or often just coding C in a slightly different way would convince the compiler to generate the most optimal assembly code for me.

8-bit CPU Architecture

I could go thru a long discussion of the block diagram of the 8051 CPU but instead I’ll just cut to the  chase – the 8051 is not at all “C friendly”. The 8051 was architected back in the bad ol’ days of assembly programming – especially for embedded systems where resources were in very short supply (think 1K ROM and 64 bytes of RAM). Thus the architecture has all sorts of funny things that a C compiler can’t take advantage of efficiently. The PSR flags, the D pointer, the single accumulator, memory mapped registers and the SFR registers are all parts of the 8051 that make it special but unfortunately are just not efficient in C. The folks at Keil have worked really hard to make their compiler as efficient as possible and to make access to these non-C hardware resources available without too much effort. But at the end of the day, a C compiler really wants a nice simple block of 32-bit registers to perform integer arithmetic on and a simple flat memory – in other words, a RISC CPU.

In the Z-Wave world, the 8051 in the 500 series chips is a 32 MHz 8051 with 128K bytes of FLASH and 16K bytes of RAM. “But wait” you say, “the 8051 is an 8-bit CPU with a 16-bit Program Counter, how can it address 128K bytes?”. The answer is Bank Switching which is just plain crazy but I won’t get onto that soapbox in this posting. The Z-Wave code from Silicon Labs is delivered as pre-compiled C libraries that the application developer links into their code. The application code is written in C and the Keil compiler does a fine job of squeezing a reasonable amount of code into the tiny 8051. Fortunately in IoT, the task to be performed is usually pretty simple – turn a light on or off by activating a relay connected to a GPIO so we don’t need a multi-Gigahertz CPU with gobs of RAM.

The Silicon Labs SDK comes with a number of sample applications and a bunch of “helper” routines all written in C. Thus, a Z-Wave application can generally be written completely in C, compiled using the Keil compiler and it’ll generally squeeze into the limited code space as long as you don’t try to do too much on this little CPU. But it seems there are always some little things that I just need to do a little faster. The following tips are just a few of the simple tricks I’ve learned from decades of embedded coding.

The Fastest 8051 Loop

What is the fastest 8051 loop you can execute in C?

The most common loop is a simple FOR loop:

for (iter=0;iter<16;iter++) {
...
}

Which is easy to read and does the job just fine – if we don’t need to do it very fast. Often the innermost loop is executed a lot and squeezing just a few instructions out of the code will significantly improve the performance of the routine.

The for loop above compiles into the following assembly code:

B02:0xA04D E4 CLR A
B02:0xA04E FF MOV R7,A
B02:0xA04F 0F INC R7                    ; TOP OF LOOP
B02:0xA050 EF MOV A,R7
B02:0xA051 B410FB CJNE A,#demodState(0x10),B02:A04F

Which as you can see is quite a few instructions and even longer when you consider that each instruction is at least 4 CPU clocks. The Compare and Jump if Not Equal (CJNE) is a 3 byte instruction which requires many clock cycles to execute. If we can squeeze a few instructions out of the loop then it will run much faster. Obviously we could code in assembly but this exercise is to show that HOW you code in C can make a big difference in the performance. An alternative coding of the for loop above is:

iter=16;
do {
...
} while (--iter);

With this slight change in the coding style the while loop turns into a single byte DJNZ opcode as shown below so this is the fastest and most efficient looping structure when targeting the 8051.

B02:0xA055 7F10 MOV R7,#demodState(0x10)
B02:0xA057 DFFE DJNZ R7,B02:A057         ; single instruction loop

The real trick to improving the performance of your code is to see what assembly instructions the code compiles into.

How to See What Your C Code Turns Into

You can’t improve the performance of your code unless you can measure what the performance is and where all the time is being spent. A classic method of measuring the performance is to set a GPIO pin high or low during specific routines. Then use an oscilloscope to observe how long the routine takes. Other options involve printing out markers out a UART or using a hardware timer to measure the duration of a routine.

KeilDebug1A simple method to observe the instructions our C code generates for our little 8051 CPU is to use the simulator built into the Keil C compiler. By default the Keil IDE does not have a simulator when using the Silicon Labs sample projects so you have to assign one. Right click on the project then select “options” then click on the “Debug” tab. Then enter “s8051” into the CPU DLL box as shown here. You can now click on Debug->Start/Stop Debug Session or press <CTL>F5. This will enter the Keil Simulator for the 8051. One thing to understand is that this simulator does NOT understand the bank switching of the Silicon Labs version of the 8051 used in the 500 series. Unfortunately you can’t debug code much using this simulator as any bank switching doesn’t work. But it will work well enough to debug small snippets of code and of course to see what you code turns into.

KeilDebug2Once the debugger opens in the IDE, click on the line of code you are interested in and the Disassembly window (use View->Disassembly if its not visible) will take you right to the line of code you are interested in as shown here. Note that the C source code is mixed in as comments in the assembly code. This helps guide you to match the C code to the assembly code which can be a little convoluted depending on the optimization the compiler has applied. You can see here that the Do-While has turned into our desired DJNZ single instruction loop.

Don’t rely strictly on the instruction count to guide your C coding style. One slow-down I often see in the Silicon Labs code is they call a subroutine, that calls a subroutine, that calls (several more) subroutines which finally just returns a value. While this may be structured C coding it is very slow in an 8051. Each subroutine call pushes and pops a number of registers and parameters on the stack and each of those takes several clock cycles to perform. Ideally a C macro is used to specify a value or a register which becomes just a single instruction fetch of the value from a register or memory instead of all this pushing and popping.

Unrolling Loops

Another easy speedup in C is to unroll short loops. A classic situation for unrolling loops is when emulating a serial protocol like I2C with a GPIO. Since the loop is typically only 8 passes you can often significantly improve performance by unrolling the loop – often taking the I2C bit rate from under 10Kbps to nearly 100Kbps.

for (bitnum=0x80; bitnum!=0;bitnum>>1) {
    I2C_SEND_BIT(data & bitnum);  // macro to set SDA then toggle SCL
}

When unrolled turns into:

    I2C_SEND_BIT(data & 0x80);
    I2C_SEND_BIT(data & 0x40);
    I2C_SEND_BIT(data & 0x20);
    I2C_SEND_BIT(data & 0x10);
    I2C_SEND_BIT(data & 0x08);
    I2C_SEND_BIT(data & 0x04);
    I2C_SEND_BIT(data & 0x02);
    I2C_SEND_BIT(data & 0x01);

Which works well for short fixed length loops but obviously won’t work in every case. The slow down with the FOR loop involves reloading the accumulator and the D pointer with various constants and the iteration value. The inline version doesn’t have any of these nor are there any delays from looping. This technique also works well on 32-bit RISC processors.

Conclusion

There are a lot more tricks when coding for small 8-bit CPUs. But I’m hoping I won’t have to bother with them for much longer and the dominance of the 32-bit CPU will finally crush the 8-bit out of existence. The price of silicon continues to drop and 32-bit CPUs are often as cheap or even cheaper than these ancient 8-bit boat anchors. The modern CPUs also come with advanced debuggers unlike the 8051 which has… wait for it… printf or worse yet simply toggling an IO. Ugh.

 

 

Whats the difference between Z-Wave and Z-Wave Plus?

There is a lot of confusion between Z-Wave Plus and older non-Plus devices.

Z-Wave_Plus_Badge_RGB_v3.1A product that is Z-Wave Plus means it has passed a rigorous certification process and thus is likely to be more reliable and have fewer issues than non-Plus devices. All Z-Wave devices are 100% interoperable and backwards compatible so a Z-Wave Plus device can communicate with any non-Plus device without issue. If you have a choice between a Z-Wave Plus device and a non-Plus device, I recommend you choose the Z-Wave Plus device because the Plus device will work better.

Z-Wave History Lesson

The timeline shows the technology trajectory that Z-Wave has traveled since its inception in 2002.ZWaveTimeLineThe timeline shows the constant improvement and evolution of Z-Wave. Initially the data rate was only 9600 bits per second. This was fast enough to turn a light or two on or off but as things progressed and you want to slowly change the color of a dozen or more bulbs, then you need a faster data rate. Thus, the increase to 40K with the 300 series and 100K with the 500 series. There are many other enhancements along the way including longer range, better RF sensitivity, lower power, more peripherals and in particular the AES encryption engine. The amazing thing though all of these improvements is that they have all remained 100% backward compatible. Even the latest chips can talk to the early 100 series chips. Granted it is only at the slower 9600 bps but it still works! So the lamp dimmer you bought in 2004 is still able to talk to the latest SmartThings hub.

The Curse of the Even Series

Z-Wave has had some mistakes along the way, after all no one is perfect. Much like the Star Trek Movies, all of the even series chips were flawed and quickly obsoleted. The developers became so fearful of the curse of the even series they skipped the 600 series and jumped straight to 700. The 200 series chips were simply buggy. Period. They had some significant power issues making them difficult to use as a battery powered device among other problems. The flaws were quickly fixed and the series replaced with the largely firmware compatible 300 series which had a long and plentiful life. Many 300 series devices are still in the market though the chips have reached end-of-life so there are limited inventories left. A small number of 300 series chip based devices are Z-Wave Plus – but that number is quite small and there are probably none left on the shelves though you could have one installed in your home. Fortunately, as we’ve seen they are all completely interoperable so no problem there.

The 400 series suffered from a marketing mistake early on – the memory that holds the firmware is One-Time-Programmable (OTP). This means the firmware cannot be updated – EVER. You burn it once, and pray it is good. This is a nightmare for developers as they have to replace the chip every time they make a new firmware build, which they typically do hundreds of times per day. While the OTP saves a fraction of cent in the cost of the chip, the drawbacks far outweigh that tiny cost.  Fortunately we developers didn’t have long to wait and the 400 series was replaced with the 500 series. The 500 series had plenty of FLASH and added the ability to update the firmware in the device even after it is installed in the field using a technique called Over-The-Air (OTA) firmware update.

Z-Wave Security – AES Encryption

One of the most important IoT devices is a door lock. Naturally, a door lock needs to be secure. Up until 2008, Z-Wave was “in the clear” meaning it wasn’t secure at all. The Security Command Class was added to encrypt all communication with banking quality AES-128 encryption which makes Z-Wave secure – or so the Z-Wave developers thought.

In 2013 it was widely published that the Z-Wave security has a weakness when a device is first joined to a network. During that process, the encryption “key” is sent to the device over the radio and it is encrypted, but the encryption key is 128 bits of 0. Since the encryption key is all zero, it is possible for someone with very sophisticated equipment to “sniff” the radio data and thus obtain the key to every secure device in the network. While this is a security hole, it requires a lot of equipment on-site at the short time when the user is adding a secure device to the network. Much easier for a burglar to throw a brick thru a window to gain access vs. hacking a Z-Wave door lock. But Z-Wave had to counter with an improvement and they did just that in 2015 – with the updated Security S2 command class.

Security S2 adds full diffe-hellman symmetric encryption to the key exchange. A number of performance improvements were also made which enables battery powered devices to be secure without spending extra time exchanging secrets back and forth. All devices certified after April 2017 are required to support Security S2.

The question of Z-Wave Plus vs. Non-Plus however is independent of Security. Since new devices have to implement Security and they are Z-Wave Plus certified, it seems like the two go together but in reality they are independent. But all new devices will have both which is good. Fortunately support for Security S2 isn’t required to be supported by Hub vendors like SmartThings, Vera, HomeSeer, etc. They will need to add support but all your older non-secure devices will remain 100% backward compatible.

The Future

Z-Wave continues to evolve and improve but continues to remain 100% backward compatible all the way back to 2002 and the initial release of the 100 series transceivers. The Z-Wave Certification program continues to be strengthened with new features and new tests that make every Z-Wave certified product better and completely interoperable with every other Z-Wave device on the market. Interoperability is the advantage Z-Wave has over the many other competing wireless protocols for IoT.

Newer devices have been tested more rigorously and use the latest chip sets for better RF range and mesh network routing algorithms. So given the choice it’s generally better to buy newer devices using the latest technology.

Conclusion

Choose a Z-Wave Plus device over a non-Plus device even if you have to pay a little more. A Z-Wave Plus device uses the 500 series chips with the latest RF technology and firmware and has been tested under the Z-Wave Alliance Certification program which is quite difficult to pass. Rest assured that the Z-Wave device you purchase today will continue to be interoperable with future versions of Z-Wave technology for the foreseeable future.

 

EU Z-Wave Summit 2018 – Amsterdam

2018EUSummit1IoT Device Testing Best Practices by Eric Ryherd

Click  HERE to see the entire presentation including my notes. If you are a Z-Wave Alliance member a video of the presentation is usually posted on the members only section of their web site. The main takeaways from my presentation are:

  • Have a written test plan
  • Use the Compliance Test Tool (CTT) as the START of your test plan
  • Vary the environmental conditions during testing
  • Test using real world applications
  • Test using complex Z-Wave networks with routing and marginal RF links
  • Test with other hubs and devices
  • Automate testing using tools like the ZWP500
  • Code firmware with failure in mind
  • Utilize the WatchDog timer built into the Z-Wave chip

The presentation goes into detail on each of these topics so I won’t duplicate the information here. I also go thru several failures of devices I’ve been working with. You learn more from failures than you do when everything just works. This is the same presentation that gave last fall in the US summit.

Z-Wave Summit Notes

2018EUSummit4There were nearly 200 attendees at the Summit – a significant increase over last year. One of the main purposes of the summit is to learn what’s new in Z-Wave and what Silicon Labs is planning for the future. The most important news at this year’s summit is the 700 series which was announced at CES in January. Unfortunately we will have to wait a bit longer to get our hands on the chips due to the purchase of Sigma Designs by Silicon Labs. The 700 series chip has been updated to match the other SiLabs microcontrollers so the silicon has been delayed a bit but they expect to ship parts before the end of 2018. Z-Wave will benefit tremendously from a real CPU instead of the very resource constrained 8051 in the 500 series. The feature I can’t wait for is the hardware debugger. We’ll finally be able to single step our C code and inspect variables and set breakpoints. No more PRINTF! Yeah!

Time for hubs to switch to Z/IP and ZWare

The very clear message of the summit is that Z/IP and ZWare are now mature and is THE gateway interface going forward. My initial brief trials with Z/IP were frustrating with poor documentation and the software really wasn’t quite ready. But with the recent release of 2.81 it would appear it is ready for prime time and I’ll have to give it another look. I was surprised by the number of gateway developers that were at the summit and most were already using at least Z/IP and many also using the ZWare abstraction layer. The SerialAPI is the interface most gateway developers have used in the past but this is a very low-level interface. There are many nuances of handling sleeping devices and the complexities of the encrypted security encapsulation when using such a low-level interface. This is where Z/IP comes in which handles nearly all of these lower level details for you. Z/IP is planned to be the only supported interface in the near future and certification costs will be significantly higher if it is not used. ZWare adds another layer on top of the Z/IP which provides much easier C++ objects relieving the developer from having to learn the details of each Z-Wave command class. See the Z-Wave Public web site for more details.

The internal Z-Wave Technical Site (ZTS) is now also available to everyone but you still have to click on “accept terms” to gain access. However the access is granted immediately so you don’t have to wait for “approval”. So anyone wanting to learn about the inner guts of Z-Wave can now do so without buying a DevKit.

Summit isn’t all work, work, work

Maker:L,Date:2017-8-26,Ver:5,Lens:Kan03,Act:Kan02,E-YThe Summit isn’t all work all day even though the days are long and filled with lots of technical information. This summit had an evening at the Rosarium park. The park has room for team building games like a maze run, archery, volleyball among other games and of course lots of food and drink. It was a nice ice breaker and a good way to get to know your fellow Z-Wave developers. The networking opportunities are a very large part of the value of attending the summit in person. The evening highlight was a performance by the “Interoperables” Z-Wave Rock and Roll band lead by Alliance chairman Mitch Klein.

Z-Wave Saved My Fathers Life

My father is a cantankerous curmudgeon but at 89 years old he deserves to be a little crusty. In his infinite wisdom at the age of 79 he decided to move away from his family here in New England and purchased a home in warm sunny Florida. He was happy he no longer had to freeze in the cold of winter but I was unhappy because now he was 2,000 miles away and I worried something might happen to him. If someone broke in or if he fell no one would know potentially for weeks. To ease my worries I applied my technical expertise and deployed an inexpensive Z-Wave based system to keep an eye on him.

HomeSeer to the Rescue

HomeseerZeeS2

HomeSeer sells a Raspberry Pi based Home Automation system with a built-in Z-Wave interface called the Zee S2. This small box needs only 6 Watts of power but contains a complete Linux computer that can serve web pages and runs the HomeSeer HS3 application. My initial system was just the HomesSeer Zee S2 ($199) and two Express Controls EZMultiPli Multi-sensors ($99) for a total cost of $300 for my peace of mind.  No monthly charges, no “monitoring fees” or any other costs so this is indeed a low-cost solution. All of the Z-Wave devices just plug in with no wiring, no batteries and everything pretty much plug-and-play. In less than an hour the system went from the box to fully installed and the web interface up and running via my phone or computer.

The HomeSeer system is accessible 24x7x365 via their portal at myhs.homeseer.com. No complex router tunneling or anything like that – just plug the Zee S2 Ethernet cord into HS3the router and then login to it from anywhere in the world. The system is secure and password protected. The HS3 application serves web pages with a status of every Z-Wave device. The HS3 application runs on the Raspberry Pi so all processing is local which means temporary Internet connectivity outages are no problem.

The HS3 user interface shown here is utilitarian which is fine for this application. HomeSeer has an easy to use IF-THEN “events” page which is quite powerful. The HS3 system constantly monitors the motion sensors and depending on the time of day sends me a text anytime there hasn’t been motion detected in the house for more than 5 hours. I placed a motion sensor next to his bed and another in the kitchen. Since he typically would get up several times each night, my 5 hour time limit rarely false-triggered. The trigger was extended longer during the day since he would be up and around the house and not in the bedroom for more than 8 hours at a time.

Nothing is Perfect

When I first put the system together, it seemed to work reliably. However the Zee S2 unit was installed at the far end of the house near the cable box. The kitchen motion

ezmultipli200
Express Controls EZmultiPli Motion Sensor

sensor was about 25′ away and the bedroom one was another 20′ away and had to pass thru several walls, the HVAC system and a bathroom. With only 3 nodes in the Z-Wave network I violated one of the key rules of a mesh network – always have more than two routes to every device. In this case I had exactly one route to each device so I didn’t have a mesh and the result was a number of false triggers because the bedroom motion sensor occasionally couldn’t reach all the way back to the Zee S2.

I was frustrated because I left what I thought was a working system but soon turned out to be unreliable. Now I was 2000 miles away and had to suffer with this system for nearly a year before my next visit to Florida. The solution was to add a few lamp modules and another multi-sensor so now I had 7 nodes with several routes to all nodes. Now the system was reliable and did not false trigger. I added an event that automatically turned on a lamp in the family room whenever motion was detected. My father really liked this feature as he always had light as soon as he entered and it would automatically turn off when he had left the room.

I thought things were pretty robust at this point but my next Achilles heel turned up rather quickly. Something caused the Raspberry Pi to crash. I couldn’t log into it and it was no longer sending me the daily emails telling me what time my father had gotten up in the morning. After nearly 2 months the system just suddenly started sending me the daily emails again. Apparently a power outage had in effect rebooted the HomeSeer system. On my next visit I put the entire system on a power strip that my father could reach so he could reset the system. I still want a power strip that has a watchdog timer function and if it doesn’t get some sort of “ping” every hour or so, it reboots everything downstream.

He Takes a Fall

At 2:39am one morning in mid-November 2017, my father fell in his bedroom. He was unable to get up. He was unable to call for help. My HomeSeer system sent me a text at 7:39am stating he had not gotten up. That seemed like an odd time for him to not get up so I tried to call him. After several calls with no answer and checking the HomeSeer system to see that there has been no changes since 2:39am I became concerned. I had the Sheriff stop by and check on him and it turns out he was on the floor, awake but unable to move. The EMTs were called and he was taken to the hospital. In just 5 hours he was already dehydrated and would have slowly died a painful death in a day or so if my system had not been in place. The Z-Wave system saved my fathers life.

Looking back on it now, I had noticed that his morning schedule had started to vary significantly from day to day. For years he had been getting up at a pretty predictable time of around 10am. But in the months prior to his fall, his schedule had started to vary from 8am to as late as 1pm in the afternoon. When we talked on the phone he said he was fine but clearly he was struggling. He enjoyed being warm in Florida and he was happy and I was confident that my Z-Wave system would alert me to any major problems which it did.

Z-Wave Multi-sensor Version 2.0 with SmartStart – Batteries not Required

Merrimack, NH March 19, 2018 – Express Controls LLC announces the release of Version 2.0 of the EZMultiPli three-in-one multi-sensor and Z-Wave repeater. The Z-Wave Plus certified device is one of the first available SmartStart devices on the market and is available for purchase now on Amazon.

EZMFrontAnimFeatures

  • Motion Sensor
  • Temperature Sensor
  • Light Sensor
  • Color Indicator Night Light
  • Z-Wave® Range extender
  • Wall Powered – No Batteries, No wires
  • Screw tab for secure installation
  • SmartStart enabled

The new features for the 2.0 version are the addition of a screw tab for secure mounting and SmartStart. The tab on the enclosure enables secure mounting in either a standard outlet or a decorator outlet common with GFCI circuits used in kitchens and baths. The tab ensures children, elders, cleaners or maintenance personnel can’t easily remove the sensor. Secure mounting means the Z-Wave network is robust and reliable since EZMultiPli typically is a key repeater in the Z-Wave mesh network. Never worry about the batteries dying since EZMultiPli is wall powered. Installed by anyone with just a screwdriver – no wires, no batteries, no damage to the walls drilling holes.

SmartStart

qrPackSigma Designs SmartStart technology makes installation easy and secure. If your home automation system supports SmartStart, the first step is to scan the QR code on the back of EZMultiPli. If EZMultiPli was purchased as part of a kit containing several SmartStart devices, the QR code may have already been scanned at the factory. The next step is to simply plug EZMultiPli into a wall outlet and it will automatically join the Z-Wave network. Inclusion should begin within a couple of minutes but may take longer if several SmartStart devices are added at the same time. SmartStart uses the latest Security S2 encryption technology for all radio communication ensuring your system is secure.

Express Controls

Express Controls provides expert consulting services for the design and manufacture of wireless Internet of Things (IoT) products for Z-Wave product development teams. Express Controls has been been developing IoT products using Z-Wave protocol since 2003 and the 100 series Z-Wave RF transceivers.  Currently we are developing Z-Wave products using the latest Sigma Designs fifth generation 500 series RF modules which enable us to quickly prototype any IoT device you can imagine.  We have resources available for PCB design and layout as well as industrial design and 3D printing to help visualize the entire IoT product quickly.   Leverage our knowledge of the nuances of the Z-Wave protocol to bring your Z-Wave product to market quickly.  

Contact

Eric Ryherd – CEO and Z-Wave Expert Consultant

info@expresscontrols.com – +1 (603) 889-4841 – ExpressControls.com

Wireless IoT Expert using Z-Wave