How to design for the Internet of Things(creativebloq.com)
creativebloq.com
How to design for the Internet of Things
http://www.creativebloq.com/netmag/how-design-internet-things-11410551
4 comments
use open source standards for communication protocols and put yours in a public datasheet with detailed info on how to parse & process.
This, a thousand times this. Because I don't want to have problems if/when your company goes under in a couple of years.
This, a thousand times this. Because I don't want to have problems if/when your company goes under in a couple of years.
The main motivation on my behalf is that it allows us to create synergy with sensors.
Company A sells door/window contact stuff. Company B sells indoor presence detectors. Company C sells plugs to dim/switch/measure appliances.
If they make their communication stack transparent anyone can jump in and combine these products to improve comfort (e.g. appropriately dimmed lights as you walk through the house), reduce the energy bill ("you're running the airco with the window open" or kill lights in unoccupied rooms) or add a level of security ("no presence inside, no appliances on but the window just opened...").
Without it you're limited to the island solutions provided by the service.
Company A sells door/window contact stuff. Company B sells indoor presence detectors. Company C sells plugs to dim/switch/measure appliances.
If they make their communication stack transparent anyone can jump in and combine these products to improve comfort (e.g. appropriately dimmed lights as you walk through the house), reduce the energy bill ("you're running the airco with the window open" or kill lights in unoccupied rooms) or add a level of security ("no presence inside, no appliances on but the window just opened...").
Without it you're limited to the island solutions provided by the service.
Or gets bought, changes focus, ...
Totally agree, especially 1 is super important and not always easy. Plan for a dual-stage bootloader from day 1 so there's always some rescue code to fall back on.
The LED comment is interesting. I've been on several HW development projects with LEDs as the main UI and early on I decided I wouldn't participate in UI discussions on general principle because it got so contentious. We actually have detailed corporate standards on what to do with LEDs but I've also heard some interesting decrees like "User shall never see a red LED because it looks like the product is broken."
The LED comment is interesting. I've been on several HW development projects with LEDs as the main UI and early on I decided I wouldn't participate in UI discussions on general principle because it got so contentious. We actually have detailed corporate standards on what to do with LEDs but I've also heard some interesting decrees like "User shall never see a red LED because it looks like the product is broken."
Yep, which is why they'll often have constant green, pulsing green or blinking green as different status indicators.
Blue leds are mainly used for novelty value, it was the most difficult color to create in leds and now that we have them ... Some info here:
http://www.youtube.com/watch?v=yusrrOPM43o
A considerable part of the population experiences eyestrain from blue leds. They can induce headaches and when used in the bedroom you risk disturbed sleep cycles or difficulty falling asleep.
Blue leds are mainly used for novelty value, it was the most difficult color to create in leds and now that we have them ... Some info here:
http://www.youtube.com/watch?v=yusrrOPM43o
A considerable part of the population experiences eyestrain from blue leds. They can induce headaches and when used in the bedroom you risk disturbed sleep cycles or difficulty falling asleep.
There also needs to be something about not making the leds any brighter than necessary, and making sure they are necessary at all.
(I would say it is a little unfortunate that so many devices end up with 'power cable correctly attached' lights. Cable modems also have an abundance of lights that are approximately only useful for making diagnostic procedures.)
(I would say it is a little unfortunate that so many devices end up with 'power cable correctly attached' lights. Cable modems also have an abundance of lights that are approximately only useful for making diagnostic procedures.)
Very good and practical requirement proposal, especially with the low interference with people. The common protocol part is also very important. I guess mostly will use Wifi, is that true? WiMedia and ZigBee are too weak to control remotely. Any new protocols may not be necessary.
Wifi is problematic due to price and power.
Wifi embeddable modules aren't cheap, non-wifi RF are available for peanuts (RFM, Nordic, ...). But you kinda have to reinvent the wheel: the content of the packets is normally limited to 32 bytes and you have to pick/design your meshing network approach. They come in all kinds of bandwidths (normally up to order 2Mbps) and for different unlicensed frequencies which you pick depending on scenario (indoor/outdoor), range and power availability (listening 24/7 won't work on batteries).
But most IoT devices with these modules will keep their protocol closed.
If you need internet connectivity you normally pick cheap RF modules for the web of thing modules and a central module with wifi/Ethernet to talk to the servers.
Bluetooth... I hate that stuff. Zigbee ... I dislike it because most vendors sell it in a UART/RSxxx interface mode (I prefer SPI).
Non-wifi RF: incredible variety of products. Wifi: just a few.
Lastly: Power. Non-wifi RF can run on a small solar cell connected to a uC with 2kb code and 128 byte RAM. Wifi will need a mid-spec uC with a few dozen kb of code to run a minimal uIP stack. Won't run on a small solar cell or battery (e.g. your phone) for long.
Wifi embeddable modules aren't cheap, non-wifi RF are available for peanuts (RFM, Nordic, ...). But you kinda have to reinvent the wheel: the content of the packets is normally limited to 32 bytes and you have to pick/design your meshing network approach. They come in all kinds of bandwidths (normally up to order 2Mbps) and for different unlicensed frequencies which you pick depending on scenario (indoor/outdoor), range and power availability (listening 24/7 won't work on batteries).
But most IoT devices with these modules will keep their protocol closed.
If you need internet connectivity you normally pick cheap RF modules for the web of thing modules and a central module with wifi/Ethernet to talk to the servers.
Bluetooth... I hate that stuff. Zigbee ... I dislike it because most vendors sell it in a UART/RSxxx interface mode (I prefer SPI).
Non-wifi RF: incredible variety of products. Wifi: just a few.
Lastly: Power. Non-wifi RF can run on a small solar cell connected to a uC with 2kb code and 128 byte RAM. Wifi will need a mid-spec uC with a few dozen kb of code to run a minimal uIP stack. Won't run on a small solar cell or battery (e.g. your phone) for long.
Very nice thoughts. I kind of agree with you on the common standard protocols, so I didn't count non-wifi RF in. I think my 2.4G wireless handset of the home phone or wireless mouse are examples. But even printers are using wifi now.
I though Nest using wifi or 4G to talk to the smart phone, is that true? We definitely want to have it cheap enough. Printers are still expensive enough to bear with the wifi cost. The rest of the devices, such as coffee machine, clock, windows, etc. everything in home and office needs certain kind of wireless enabled sensor/receiver kind of attachment, cheap but connecting to the controller (either pc or smart phone or remote control) via internet. Pure RF connection cannot be called IoT, right? And it's not flexible, intelligent enough to be recognized from device to device.
You solar powered energy is also a good point.
I though Nest using wifi or 4G to talk to the smart phone, is that true? We definitely want to have it cheap enough. Printers are still expensive enough to bear with the wifi cost. The rest of the devices, such as coffee machine, clock, windows, etc. everything in home and office needs certain kind of wireless enabled sensor/receiver kind of attachment, cheap but connecting to the controller (either pc or smart phone or remote control) via internet. Pure RF connection cannot be called IoT, right? And it's not flexible, intelligent enough to be recognized from device to device.
You solar powered energy is also a good point.
Nest is wifi, the second generation added 802.15.4 - but I never dealt with the product.
Which is kind of a shame. The internet got part of its breakthrough because it became tech agnostic on the low layers. Token ring? Optical? Cable? twisted pair? no worries, you can hook it up.
SDR could provide a solution in that field. But there's a good chance that patents/licences will be cumbersome, just like the current situation with wifi.
BTW, if you're looking for a good wifi embeddable module: Carambola 2 by 8devices is a solid product. I recently built a WEP-wardriver with one and it took just an evening of scripting and soldering.
Pure RF connection cannot be called IoT, right?
Which is kind of a shame. The internet got part of its breakthrough because it became tech agnostic on the low layers. Token ring? Optical? Cable? twisted pair? no worries, you can hook it up.
SDR could provide a solution in that field. But there's a good chance that patents/licences will be cumbersome, just like the current situation with wifi.
BTW, if you're looking for a good wifi embeddable module: Carambola 2 by 8devices is a solid product. I recently built a WEP-wardriver with one and it took just an evening of scripting and soldering.
I got your point, very constructive. Here is my thought:
1. Bridge between the RF module and the internet If all the processing is done on the host pc side, leave the device only having the sensor to detect the state and being driven by the host pc, then it will be a lot easier to build the device itself, don't need that much functionalities. This should be the direction.
2. Transmission mechanism should not be a problem except the worrying about the wifi cost since it has all the necessary functionality built in with encode/decode, security and compression/decompression which becomes a heavy burden on the device side. But it should be easy to resolve by embedding a Linux kernel with the wifi stack.
3. SDR might be a solution to deal with various RF protocols, but do you think the performance will be compromised than using the hardware components?
So all of the available or to be defined protocols and mechanisms can be tested out if the platform supports simple/thin devices. Your proposed embedding wifi module is a very good solution to meet this requirement. Do these products have FPGA or SoC with UART or SPI interface?
If you are interested in further discussion, maybe we can take it offline. Shoot me an email at danmark.clara _at_ yahoo dot com.
1. Bridge between the RF module and the internet If all the processing is done on the host pc side, leave the device only having the sensor to detect the state and being driven by the host pc, then it will be a lot easier to build the device itself, don't need that much functionalities. This should be the direction.
2. Transmission mechanism should not be a problem except the worrying about the wifi cost since it has all the necessary functionality built in with encode/decode, security and compression/decompression which becomes a heavy burden on the device side. But it should be easy to resolve by embedding a Linux kernel with the wifi stack.
3. SDR might be a solution to deal with various RF protocols, but do you think the performance will be compromised than using the hardware components?
So all of the available or to be defined protocols and mechanisms can be tested out if the platform supports simple/thin devices. Your proposed embedding wifi module is a very good solution to meet this requirement. Do these products have FPGA or SoC with UART or SPI interface?
If you are interested in further discussion, maybe we can take it offline. Shoot me an email at danmark.clara _at_ yahoo dot com.
I just heard a talk with Sproutling's CEO Chris Bruce. He really recommended reading this book: http://www.amazon.com/From-Concept-Consumer-Ideas-Money/dp/0...
You should also attend the SF Hardware Startup meetup, run by my friend Nick Pinkston (great guy): http://www.meetup.com/HardwareStartupSF/
You should also come and join us at the Hackendo::Integrate conference in April: http://hackendo.techendo.co/
You should also attend the SF Hardware Startup meetup, run by my friend Nick Pinkston (great guy): http://www.meetup.com/HardwareStartupSF/
You should also come and join us at the Hackendo::Integrate conference in April: http://hackendo.techendo.co/
I think the "Unix Philosophy" is way ahead on this one. http://www.faqs.org/docs/artu/ch01s06.html
Rule of Least Surprise: In interface design, always do
the least surprising thing.
Rule of Silence: When a program has nothing surprising to
say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as
soon as possible.Interesting rules. I can feel they are right. But if all the UIs are not surprising, people will be pretty bored and hard to remember to come back. This is a dilemma for my website UI design.
You can minimize surprise by always immediately crashing. There will be a slight learning curve, but rather quickly a user will never be surprised by your UI again.
This is interesting, can you elaborate or provide and example? Thanks!
It was meant to be amusing, not interesting... The idea is if the only thing your program does is crash, users will expect it to crash, and so it will never do anything unexpected (or useful) like "not crash".
That totally went over my head! I was thinking you might have had a philosophy that forces users up a steep learning curve more quickly, whoops!
For myself, I find the best way to have a shallow learning curve for me is to define the interface as I go (building out keybindings in ratpoison as I want them, &c). Leaves it pretty impenetrable to others, though. I think that last bit is more bug than feature.
Very good solution outlook. The main concern I have is: "Design for scale of everything", given the example of 200 bulbs. That's exaggerated, but how about you have 200 of IoT at home? Do you use 200 or 100 apps to control them?
This is the problem of Nest which has the architecture of producing one thing after another controlled by smart phones. This architecture does not scale.
This is the problem of Nest which has the architecture of producing one thing after another controlled by smart phones. This architecture does not scale.
Would you think that a "platform" do unify all this smart devices - makes sense?
Yes, I think so. It's under development.
Other than that, if we build each smart device like Nest's, the cost is not acceptable when we are going to have 100 at home, all of which cost > $100 and have so many different apps to control each of them.
The current trend in the public is: making each device HTTP-enabled so that they can talk directly to the web server in the cloud, which in turn to talk to the mobile devices or controller, and vise versa. I see a pretty good implementation here: http://ronguest.com/blog/2013/10/how-to-run-temboo-from-open...
This is a solution that minimize the cost for realizing the IoT available so far. But it still does not scale. The design requires to upload a Python SDK to the memory of the second chip and requires SSL for security. SSL is slow in terms of the performance of a device response. It's redundant. Wi-Fi itself is very secure if the message can be transported on a lower level.
Alternative solutions could be: unify all the smart devices at home using home computer as a central control which will send messages back and forth to the smart phone or remote control. Between the central controlling program and the devices, some type of communication either on the HTTP level or lower level will help. It's not necessary to bring everything onto the Internet, only the web server on the home computer is exposed, which is a lot more secure. This way, your smart phone only need to have one app to control all the smart devices at home.
More aggressive solution is to control the smart devices on a lower level than HTTP from the cloud, so that the cost of building the smart devices can be reduced significantly, keeping the device price minimum change from the traditional devices. That's in the future.
Other than that, if we build each smart device like Nest's, the cost is not acceptable when we are going to have 100 at home, all of which cost > $100 and have so many different apps to control each of them.
The current trend in the public is: making each device HTTP-enabled so that they can talk directly to the web server in the cloud, which in turn to talk to the mobile devices or controller, and vise versa. I see a pretty good implementation here: http://ronguest.com/blog/2013/10/how-to-run-temboo-from-open...
This is a solution that minimize the cost for realizing the IoT available so far. But it still does not scale. The design requires to upload a Python SDK to the memory of the second chip and requires SSL for security. SSL is slow in terms of the performance of a device response. It's redundant. Wi-Fi itself is very secure if the message can be transported on a lower level.
Alternative solutions could be: unify all the smart devices at home using home computer as a central control which will send messages back and forth to the smart phone or remote control. Between the central controlling program and the devices, some type of communication either on the HTTP level or lower level will help. It's not necessary to bring everything onto the Internet, only the web server on the home computer is exposed, which is a lot more secure. This way, your smart phone only need to have one app to control all the smart devices at home.
More aggressive solution is to control the smart devices on a lower level than HTTP from the cloud, so that the cost of building the smart devices can be reduced significantly, keeping the device price minimum change from the traditional devices. That's in the future.
- Always provide a way to auto update and fallback if failed.
- never implement a buzzer or beeper.
- stay away from blue status leds. people really dislike them, especially in the bedroom.
- always design with sleep/low power mode functionality. If it's embedded uC: 1 watt is more than enough, even with RF. Pick bistable relays. If it's a Linux SoC aim for less than 3W. If there's wifi keep it under 21 dBm. Pick sps modules like 78SRxx from murata instead of linear 78xx.
- if it's a thing you plug in the wall socket make sure it doesn't obstruct other sockets.
- expect people to unplug it every moment every day.
- don't force people to provide an email to activate some functionality or feature.
- use open source standards for communication protocols and put yours in a public datasheet with detailed info on how to parse & process.