4 ms·

Have a bit of experience in this field, on a technical side: - Always provide a way to auto update and fallback if failed. - never implement a buzzer or beep

by jmpe 13y ago

Have a bit of experience in this field, on a technical side: - 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.

angersock 13y ago
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.
- dllthomas 13y ago
  Or gets bought, changes focus, ...
- jmpe 13y ago
  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.
zwieback 13y ago
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."
- jmpe 13y ago
  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 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.
dclara 13y ago
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.
- jmpe 13y ago
  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.
  - dclara 13y ago
    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.
maxerickson 13y ago
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.)
tumba 13y ago
+1 for #3 (blue LEDs). A couple weeks ago I spent a half hour taking apart an air purifier in my bedroom and disconnecting the blue LED because it was so obnoxious.
- baldeagle 13y ago
  A little tape and some nail polish will take care of most of that. Skip the tape if you don't plan to sell/undo it.

by jmpe 13y ago

angersock 13y ago

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.

dllthomas 13y ago
Or gets bought, changes focus, ...
jmpe 13y ago
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.

zwieback 13y ago

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."

jmpe 13y ago
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 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.

dclara 13y ago

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.

jmpe 13y ago
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.
- dclara 13y ago
  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.

maxerickson 13y ago

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.)

tumba 13y ago

+1 for #3 (blue LEDs). A couple weeks ago I spent a half hour taking apart an air purifier in my bedroom and disconnecting the blue LED because it was so obnoxious.

baldeagle 13y ago
A little tape and some nail polish will take care of most of that. Skip the tape if you don't plan to sell/undo it.