Arduino Sensor Plugin - Build your own wireless sensors!

Plugins & Plugin Development Unmaintained
81

The distance sensor is surprisingly accurate. Should work very well for your project!

Don’t know how it will survive long time exposure to moisture in the tank though…
3 batteries will give 4.5 volt which would give enough power and can be connected to the unregulated Vcc input of the pro mini.

82

hek, thx 4 update!
bug report: RelayActuator - stop working. ver #28 - work fine

83

Yes, moisture will be the big problem. Thank you for the advice for the batteries and voltage.

84

@mitekdg
What parts did you update? Both plugin, library and relay sketch (using new library)?
Did you also update the ArduinoGateway sketch using new library?

Next step to debug is:

Have a look at Vera logs. Is data coming in from sensor?

grep Arduino /var/log/cmh/LuaUPnP.log

Also have a look at the serial output from relay sketch Tools->Serial Monitor

85

  1. gateway - updated

  2. lib - updated

  3. relay sketch - updated
    non working

  4. gateway - updated

  5. lib - old ver28

  6. relay sketch - old ver28
    working

86

And vera plugin version?

Please check vera logs if we can find any problems there…

87

updated vera plugin.
ver 1.2

how to get this data from vera?

88

You need to ssh into vera and run the command above.

Maybe it’s better to look at serial log on relay first. Hook it up to your computer and select Tools->Serial Monitor in the Arduino IDE.

Then turn on/off relay in vera/browser and look at the output.

89

I might have found something… w8 a bit…

90

Found a problem in vera plugin. It manifested itself when a sensor requested an id.
An updated “L_Arduino.lua” has been checked in.

@mitekdg
Was your problem that no device showed up at all?

91

yes. no device showed up.
Now i’ll try a new version.
thx

92

work perfect! thx

93

[quote=“hek, post:77, topic:176573”]New release… see wiki for details…

CHANGES 1.2

  • Added possibility to request time from vera
  • Support for 5 custom variables (can be stored in any sensor device).
    Note that chixxis variable container is still not supported. But
    the functionality is similar.
  • Sensors reports their library version to Vera.
  • New example sketch showing time and variable functionality
  • SendCommand action added in vera plugin which makes it possible to send
    data to sensors from scenes (advanced-section) or via luup-calls.
  • Auto-id added. A sensor can now request id from vera at first start.
    The id gets stored in the sensors EEPROM.
    All example sketches now uses auto-id functionality.
    You can still use static ids if that is preferred.
  • Fixed “No Implementation” message when pressing Armed/Bypassed on security
    sensors.
  • Automatically sets LAST_TRIP and BATTERY_DATE
  • Cleaned up plugin code[/quote]

hek, could u give some example to work w/variables. And another question is how can i send a battery lev from sensor.
thx

94
* New example sketch showing time and variable functionality

You’ll find the example for variables and time here:
http://code.mios.com/trac/mios_arduino-sensor/browser/trunk/Arduino/TimeAndVariableSensor

Sending batterydata should be done by (note that I have not tried this myself yet):

vera.sendVariable(CHILD_ID, V_BATTERY_LEVEL, 50); // 50%

95

[quote=“pat38, post:41, topic:176573”]Hi Hek,

Thank you so much for sharing this plugin!
I have a Vera since last Saturday, and I have immediately looked for a way to interface the Vera with my IR remote control (logitech harmony) to control the lights, and was disappointed not to find no solution at less than 100?.
I know pretty well Arduino, and the great IRremote library from Ken Shirriff’s (A Multi-Protocol Infrared Remote Library for the Arduino), so finding your plugin was a bless to put me at start on a cheap IR interface solution (approx 10?) :smiley:
Thanks to your example, I had the plugin working on Sunday: for now it simply executes scenes with predefined names when I press buttons on the remote.
I am now trying to have the plugin generate events instead of directly running scenes, so that I do not have to use any particular names for the scenes… I am struggling with this for now: the documentation for luup is one of the worst I have ever seen :frowning:

Anyway, thank you so much for this plugin! It is a great idea. I am sure I will be using your plugin in full very soon!

(for the IR plugin, once finished, I will post my plugin in a different thread. I do not want to pollute your thread, but just to say thank you :slight_smile: )

Cheers,

Patrick[/quote]

Nice idea!

Just bought this:
http://www.aliexpress.com/item/2PCS-Digital-38KHz-Infrared-IR-Sensor-Transmitter-Kit-for-Arduino-M3AO/1178542936.html

I’ll incorporate this into the plugin so we can send/reveive AV equipment IR signals when the stuff arrives.

96

The wiki has been updated with a purchase guide for getting started.
http://code.mios.com/trac/mios_arduino-sensor/wiki#Buyingguide

97

and another feature request ))

  1. Security token (aka pairing vera-gateway vs. “sensor”)
  2. Mesh network of nrf24 dvcs or relays for distance improving.

IR extender will be great solution!

Hek, u r genius! THX!

98

What do you mean by security token? Some sort of AES key exchange and encrypted traffic would be the best but it would require quite complex handshaking and probably larger messages. But it would be nice, I agree… someone up for the challenge or having clever ideas, please let me know.

I see a couple of problems using nrf24 network. Relay nodes must always be “on”, ready to relay message. Which means no battery devices.
The node addresses (16bit) is also used to set topology would require me to redo the whole auto-id and message structure. It would be a quite a bit more complex for novice users to setup their sensor network. I really like the idea of a z-wave network better where nodes auto-configure their topology and routes. Don’r really know if I have the time to implement that type of behavior though.

99
  1. 2 purposes: pairing devices, so 1 device can interact with 1 gate, and the second one - secure (encrypting) messaging
  2. Yes, the relay nodes must be always on-line, but it will allow to increase the range of network. Have u seen the maniacbug RF24Network meshnetwork example, its very easy to configure. Auto-config is excellent solution, but very complex, i think manual config will be enough

p.s.: sorry for my english

100

i have some thoughts about mesh and encryption

  • encryptions a nice thing to have but it costs hardware and it will slow down implementation.
    I thing we should thing about two different things:
  1. authentication
  2. encryption itself

the first one can make our network more consistent because we can be sure that we react to the message of “a right” format from “a right” pair.
it can be archived by a few different ways:

1.1) simple check for the message body using our unique function. For example we can put one byte CRC to check that the rest of the message is matching CRC. If there is no match device should ignore the message assuming that message is of wrong format, wrong version, wrong pair etc.
1.2) through key-exchange algorithm - before two devices will communicate (or any new device will communicate with a gateway) a right format keys should be exchanged:
1.2.1 using any simple arithmetic function - will require about zero of additional programming and memory code but will be also zero resistant to intruders
1.2.2 using good encryption algorithm like DSA/RSA etc. It will be much more protected from the intruders but will require 1-4kb of programming code
after key exchange we should send a right key with each message. Probably key should have an expiration leading to the next key exchange session.

encryption can not only make a network more consistent but also will protect it from stealing and from hacking
2.1 software encryption using for example GitHub - DavyLandman/AESLib: Arduino Library for AES Encryption (source based on avr-crypto-lib)
2.2 hardware encryption. Most atxmegas have hardware encryption but this will require to build a custom hardware

because 1.2.2 requires the same additional program code as 2.1 it probably a reason to use just encryption without authentication (encryption will act also as authentication using private/public keys)

but the cost… I personally will prefer to build network faster less secured instead of slower and secured. I do not plan to put locks using arduino and i have nothing against someone listen to my sensors. But at least 1.1 or 1.2.1 is nice to have - this will reduce dramatically a probability of unexpected behavior.

network

  • i think RF24Network is not a good solution

i’m thinking of:

  • keeping simplest design of end-user devices
  • add relays. You will just need a few of them across the house
  • relays can relay message both ways
  • they should have powered from the outlets, not batteries.
  • relay can be at the same time an end-user device but not necessary
  • relay should acts as a gateway to end-user device if end-user device was configured to talk with relay instead of GW
  • relay can talk to GW using another relay (not needed at first step but will allow to brake a restriction on a distance from a device to GW)
  • ID generation by vera&GW should also include relay assignment. Etc. wile adding a new device we should take vera & GW close to a new device and initiate ID & relay assignment. It can be like this:
    • vera sendsa new ID to device
    • device announce itself to the network
    • first replying relay should be recorded by a device as relay
    • relay should record a device as neighbor
    • relay should announce a new device as it’s neigbor to it’s relay (including GW itself)

this way:

  • relay will knew it’s neighbor
  • device will knew it’s relay
  • GW will knew all devices and their relays

the path can be constructed on the fly relaying one through one