search

skalpt / purple-elephant

0 stars 0 forks source link

Product Ideas #2

Open skalpt opened 10 years ago

skalpt commented 10 years ago

This issue/case is to keep track of ideas for products.

skalpt commented 10 years ago

De-Pa commented:

  • Support for other country power sockets
  • Support for 110V
De-Pa commented 10 years ago

Comment relates to #1. Moved to #1.

~~Everything goes back to master for control; no override so, for example, infrared receiver can override temperature sensor. Redundant switches in series -> 1 off = all off; in parallel -> 1 on == all on: use series/parallel block so customer can decide Infrared receiver doesn't control anything; it goes back to the master which controls whatever Temperature sensor can sit on any socket in the room~~

Problem with all this is that it may be difficult to set-up the control in the first place; we want any old dummy to be able to do a standard set up with more intelligent users able to 'get into the controls' to do more sophisticated things.

De-Pa commented 10 years ago

Tentative sensor diagram here, with some questions to consider?? sensor diagram 2013 12 11

De-Pa commented 10 years ago

This makes the master pretty complicated/sophisticated???

skalpt commented 10 years ago

I think the current state of all nodes needs to be stored in the cloud so there is one source of truth. A factory-standard Master Receiver will need to provide interfaces for USB, Ethernet and WiFi connection. Regardless of how it is connected, the receiver should try to upload all data to the cloud. In the event that Internet is down, the front-end application would not be able to provide any overall stats. However, upon clicking on a specific node in the application, the application would query the Master Receiver over LAN and provide that node's status.

skalpt commented 10 years ago

Infrared receiver doesn't control anything; it goes back to the master which controls whatever

Then forget about IR. Just make it 2.4GHz and let it communicate directly with the master, same as the nodes would. Should also add a little OLED screen so you can scroll through your devices and pick which one you want to view/control.

De-Pa commented 10 years ago

So what would a block/control diagram look like (as opposed to what I thought we were considering and which would have needed a computer as the master)?

skalpt commented 10 years ago

It will need a PC for the first few prototypes, until we build Ethernet/WiFi support into the Master Receiver. At that point, I would envision the network diagram looking something like below. Note that the receiver uploads data directly, without the aid of a PC.

high-level-network-diagram

skalpt commented 10 years ago

Motion Sensor: Would need an option for running off batteries so it can be mounted anywhere. Will need to have very low power consumption.

skalpt commented 10 years ago

Irrigation System: Particularly for home gardens. Would use a solenoid valve with a tap fitting. Leakage at the fitting would be the be biggest concern, probably want a one-way valve on the fitting itself. Could also add a flow meter to measure water consumption.

De-Pa commented: Can buy solenoids (like at Mackay). Leaking is not our problem; we only have to worry about turning them on and off.

skalpt commented 10 years ago

Security Camera: Take real-time photos of your house from anywhere in the world. This already exists, but probably not integrated with this many other products. Security Alarm: Remotely trigger a security alarm, or have it triggered automatically from the motion sensor, etc.

skalpt commented 10 years ago

Curtain Opener: Love this idea but cannot think how to make a universal fitting nor a way to attach it to the wall.

skalpt commented 10 years ago

Remote Wakeup/Shutdown: Again, done a zillion times before but our application should have a function to wake up (WOL) or shutdown a PC remotely.

skalpt commented 10 years ago

I think every product should have a cheap LCD screen on it so you can use it as a standalone product without the receiver if you don't want to buy one. Ideally nodes should also be able to talk to each other, so that if the receiver is offline or out of range a temperature sensor can still trigger a remote switch. Would be nice if nodes could also automatically relay messages if the originating node is too far away from the receiver.

De-Pa commented: How about an LCD screen option? Otherwise every product has an LCD screen which would raise the base price, packaging complexity etc?

skalpt commented 10 years ago

Christmas Special: Big net of RGB LEDs (like the ones in the display windows of iPhone stores, see photo below). PC interface to design images to display on the LED "net", and when it turns on/off.

led-net

skalpt commented 10 years ago

Want to be able to push software updates from the cloud to the receivers, and even the nodes. Also want to support user-submitted plugins (or at least an API for 3rd party applications).

skalpt commented 10 years ago

Light Sensor: Define a certain threshold of light to trigger other nodes

skalpt commented 10 years ago

"Sensing" nodes should be able to trigger individual or even groups of "controlling" nodes. For example, when it gets dark I might want my light sensor to switch on three lights in the hallway. I may even want a temperature node to switch on one heater when it's cold, two heaters when it's freezing and a fan when it's hot. Different scenarios can be linked to different groups of devices.

De-Pa commented: So somewhere there has to be to be 'smarts' to link sensors to actions. Timer: In the 'smarts', able to set up timers to turn actions on and off.

skalpt commented 10 years ago

How about a big tablet-like device for mounting on the wall?

skalpt commented 10 years ago

Remote Music: Play music from the PC/iPhone/Internet in any room(s), from anywhere. A squeezebox solution for our brand. No speakers, just a receiver with a few audio jacks to link into an existing audio system. Remote Video: Our answer to Apple TV. Could look into an option with a built-in TFT screen (they are very cheap these days)

De-Pa commented: Wall Pictures: Change your paintings or perhaps just cycle through your photos.

skalpt commented 10 years ago

Although all long-term data (historical/non-real-time) should be stored in the cloud, an iPhone/PC on the same network as the master should be able to interface through the LAN. Will allow for much faster communication, better security (you have already entered a WiFi password to connect to the network) and Internet redundancy. A PC should also be able to collect/store data in the event that:

  1. The LAN is not connected to the Internet; or
  2. The user has not set up and/or agreed to a cloud account.

De-Pa commented: Back your settup up to a USB stick.

De-Pa commented 10 years ago

Implementation:

  1. Think of everything we want the system to do -> requirements
  2. Design the system so it can achieve all the requirements
  3. When confident we have requirements determined, make prototypes of the first products
  4. Make 20 off first product (say) in garage
  5. Offer on E-bay
  6. Repeat 4 & 5 until have so many can 'farm-out' manufacture
  7. Add product and repeat steps 4-6
  8. Once have volume, market through Woolies/Bunnings etc (under different name(s)?)
De-Pa commented 10 years ago

Security: Multiple layers such as

  1. Keep master production separate from unit production (ie outsource to different company)
  2. Keep all programming in house
  3. Include something like state machine (that burns-in functionality) in the kernal of the master
  4. Embed master in resin (so difficult to reverse engineer)
  5. Build 'self destruct in case of tampering' into master?
skalpt commented 10 years ago

Moved to #5.

Once have volume, market through Woolies/Bunnings etc (under different name(s)?)

Also like the idea of:

skalpt commented 10 years ago

Alerts: Email/SMS the user on a certain threshold - e.g. temperature gets too hot, current too high, intruder passing motion sensor, etc. Email alerts will already be natively supported through the master. SMS would be a separate rcBlock.

skalpt commented 10 years ago

Voice Activated Block: Allows you to control other blocks using voice commands.

De-Pa commented 10 years ago

Would need lots of smarts to interpret the voice commands! Where would that be? I could envisage a 'remote' that you carry with you and talk into.

De-Pa commented 10 years ago

Could have a similar push-button remote like a TV remote to turn lights etc on and off. Ideally, would use a standard IR remote that can be programmed to direct an IR receiver block.

skalpt commented 10 years ago

Would need lots of smarts to interpret the voice commands! Where would that be? I could envisage a 'remote' that you carry with you and talk into.

Carrying around a remote defeats the purpose of it being voice activated. Would need to have voice recognition integrated into the hardware. Something like this: https://www.sparkfun.com/products/12656

skalpt commented 10 years ago

Could have a similar push-button remote like a TV remote to turn lights etc on and off. Ideally, would use a standard IR remote that can be programmed to direct an IR receiver block.

Cool idea. Use the power button on your tv remote to turn off the lights :)

skalpt commented 10 years ago

Basic vs. Premium Blocks: Was chatting with someone last night who has a lot of market knowledge in this field. He recommended that rather than designing the product in such a way that the consumer is required to plug a temperature block into a current block into a switch block (this is going to protrude a long way from the wall), we market a cheap/basic switch block and an advanced/premium switch block, the latter of which incorporates the temperature and current sensors. Current and temperature blocks should still be sold separately, but if someone wants to automate their entire home and monitor their energy usage at the same time, they shouldn't have to plug in two blocks per outlet - too cumbersome.