Front Door Fun

[Julian Knight]

Hi all, just wanted to let everyone know that, if you have access to a Clas Ohlson, their Nexa range of wireless devices work nicely with the RFXCOM RFXtrx433E (and the Telstick which CO sell) and hence nicely with Node-Red.

Just brought one of their door bell/push combo's today and got it working in just a few minutes. So now when someone rings the front door bell, not only does it sound the ringer but also sends me a message using PushBullet! Thanks to the work I'd already done, this also sends messages out via MQTT so that I can add further processes when the bellpush is used. It also saves the event to MongoDB each time so I have an ongoing record of when the doorbell rang. Probably pretty pointless but fun none the less! :)

Of course, I can also manually sound the ringer so as to scare the cat/kids (take your choice!)

[Shem Jamieson]

Yep - Very handy knowing that your doorbell was pushed when you are out… And why not save each doorbell press to a DB, storage is cheap and you never know when that information could come in handy!

[Mike Biddell]

can you mail an IP camera picture too????

[Julian Knight]

Ha ha!  That's next! :) Along with wiring up a Pi with microphone and speaker so I can talk to the person at the door.

Do you think it might be going too far to have a video screen so they can see me as well ?? ;)

Or maybe a quadcopter in a housing on the roof that I can fly down and inspect them? Node-Red takes over the world!

[Nicholas O'Leary]

A quadcopter controlled by Node-RED? Madness... https://www.youtube.com/watch?v=doTDx-a79Vs ;)

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julian Knight]

Ha!! Knew I should have taken that job with IBM!!

Now I'm going to have to save up for a drone!

[Paul Reed]

Julian,

Martin Harizanov explored this a couple of years ago (pre Node-RED) by hacking a doorbell and writing a script to capture a photo and email it to him. He documented it in this blog post if it helps.

Paul

On Tuesday, 21 April 2015 22:32:04 UTC+1, Julian Knight wrote:

[Nicholas O'Leary]

Some of us having been playing with this sort of thing for a while.... http://knolleary.net/2008/04/13/getting-the-doorbell-online/ :)

--

[Mike Biddell]

I already have doorbell, picture, email on my Ninjablock. But the operating system is so flakey, it is unreliable. I have just ordered RFXCOM 433 and want to replace the Ninjablock with node red. So emailing IP camera pictures is a necessity for me, if I am to replace the block with a device which has the same functionality. I have not seen any posts from other users about IP camera pictures, so not sure whether anyone has achieved it !!! 

[Dave C-J]

by default the e-mail node will accept a binary buffer (image) and convert to an attachement - so you should be able to just use an inject (or other trigger), an http request node (to get the picture) and the e-mail out node to send it...

[Julian Knight]

And if all else fails, you can still call out to external applications to do the job.

[Dave C-J]

Though if they do fail, we would rather get a bug report and fix it...

[Mike Biddell]

Dave.... as soon as my RFXCOM arrives, to sense the door bell, I'll try it and report back..... I also have a 433 contact on the letter box (my postman is the most photographed human on the planet). I also have a 433 PIR on the drive which triggers the IP camera. My neighbours cat "white boots" is also frequently caught on camera. I think he likes weeing up my car wheels !!!!

I may need Max's help in setting up the RFXCOM. Presumably its just an NPM install !!!!! And then import Max's flows.... hope so.

mike

[Mike Biddell]

Oh or Julian's help.... he has set up RFXCOM too !!!!

[Julian Knight]

Yup! You'll be glad to know that since Max's last update, the installation is nice and simple. I have it plugged in to a Pi2 along with a Ciesco Slice of Radio (SRF). The SRF collects data from an Arduino - also over 433MHz - and will collect from a bunch more when I can get round to making them. The RFX collects data from an Oregon Scientific sensor, a Home Easy PIR, a LightwaveRF remote control and now a Clas Ohlson door bell push and sends to a CO door bell sounder and a bunch of LightwaveRF switches.

I'll be adding more switches, I plan to have around 7 or 8. I also plan to create more temperature/humidity/light sensors and a sensor for reading how much electricity the house is consuming. I may even resurrect the robot I built with my son and put it under NR control if I can ever find the time. I also want to find a way to reliably detect who is in the house and change settings accordingly, add some more motion sensors, add remotes to the ceiling lights (that people are always leaving on). Eventually, I'll get a smart heating controller too. Maybe when the price comes down a bit. The home hub web site is also taking shape too.

Then there is the idea for a Pi based alarm clock with music and wake/sleep lighting.

I guess that should occupy me for a few years!

So much to learn, so much fun! Beats watching rubbish TV ;)

[Mike Biddell]

Julian

I'm with you all the way..... in my case, I don't have enough life left to execute most of the ideas !!!!!!! I automated my hall and stair lights recently a moving led strip lights the steps via a motion sensor....looks like the star ship enterprise, and you can mix many different colors and alter the speed. I have great hopes for node red, as have designed and partially built an automatic watering system for my garden. So I have great hopes for RFXCOM too. Wonder if it could read my Eco-eye solar meter ?

Mike

[Julian Knight]

Hi Mike, glad I'm not the only mad person. What LED strip are you using? Can it be controlled from the Pi?

[Mike Biddell]

Julian

This is the strip:- http://www.ebay.co.uk/itm/5M-5050-RGB-LED-Strip-Light-Power-Supply-Adapter-44Key-IR-Remote-Waterproof-Kit/141293486134?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D30111%26meid%3D71a74c1795954855bb63b04baf91891b%26pid%3D100005%26rk%3D3%26rkt%3D6%26mehot%3Dpp%26sd%3D171522956847&rt=nc

I found some self adhesive trunking at Wickes, which is quite transparent and the LEDs easily shine thru.

The power supply is in a hall cupboard and is controlled by a 433 socket. My Ninja block is controlling it at present. I have a 433 motion sensor at top and bottom

of the stairs, and as soon as Ninja detects motion, he sends ON to the 433 socket to turn on the strip. Ninja then waits 3 minutes and sends OFF. The power wires run under the hall carpet.... it's very neat, but visitors are quite impressed and my granddaughters keep mixing strange colors using the remote.

I presume all this is do-able with node red and rfxcom.....you should treat yourself... it's great fun and not expensive.

I'll give you a shout when I get the RFXCOM, if you don't mind,  dont want to make any mistakes with the install !!!! 

Mike

[ryan...@gmail.com]

Hi Julian,

Mike's approach of an automation controlled relay controlling an LED kit with driver/remote is perfectly good but if you want a bit more flexibility (e.g. control colours/fade on command from NodeRed) these cheap strips can be driven pretty easily by a Pi or microcontroller. You just need 3x PWM pins to switch the RGB grounds, MOSFETs or a cheap pre-made RGB amplifier (about £6 on ebay) to sink the current and a 12V power supply. I'm currently scaling it up a bit and combining an Arduino Mega + PWM daughterboard to give me enough PWM to control a dozen separate strips, all talking JSON/MQTT back to NodeRed over ethernet 8)

I've also done similar stuff with the addressable LED strip, that's really cool and lets you change each LED individually, but the strip itself gets a bit spendy... If you need any help just ask.

Oh and one other useful tool for your home automation arsenal: http://www.ebay.co.uk/itm/Standard-Pressure-Mat-for-Intruder-Alarm-System-PM2-/380230648927 - I use these under carpet, in stairs and doorways etc. No power source needed, very reliable and a piece of cake to wire back to a microcontroller/Pi. Handy to correlate with PIR sensing to get a more accurate occupancy.

Ryan.

[Dave C-J]

Or the Blinkstick from http://www.blinkstick.com can also drive strips direct from a USB - is available as a kit or pre-built and has a node - https://www.npmjs.com/package/node-red-node-blinkstick

[Julian Knight]

Arrggghhh!! Too many options!

I'd probably go for Mike's simplicity to begin with. It looks like a fun, easy and cheap project. I've already got a PIR in the hallway, another on the landing would make it work. In fact, in our old Victorian house, the landing is always dark so some low cost lighting with a couple of PIR's would be ideal. Going to be decorating hall and landing shortly so probably a good time to be thinking about it.

Then a step up to Ryan's suggestion. The main issue I would have is where to put a controller. This is the issue I've had all along. I don't really want to tie something into the Pi because that will limit where I can put it. Ideally, I would like to be able to put an Arduino clone with cheap wi-fi such as one of the ESP8266's (serial to Wi-Fi) that Peter Scargill has been espousing on the job. Ryan, do you know of any blog posts or instructables doing what you've suggested?

While the Blickstick looks interesting Dave and thanks for pointing out that they've move beyond the original which I never really saw the point of - having an LED sticking out of your PC! - it would tie me to the location of something with a usable USB port - the Pi probably.

Thanks all for the ideas - loving it.

[ryan...@gmail.com]

Here's a good primer on the DIY hardware approach complete with arduino code: https://learn.adafruit.com/rgb-led-strips/overview 

Unless you have the MOSFETs lying around i'd personally just get a pre-made RGB amplifier like this one: http://www.ebay.co.uk/itm/Signal-Amplifier-Repeater-For-DC5-24V-12A-LED-5050-3528-RGB-Flexible-Strip-Light-/281282197785 - be wary of the tiny in-line amplifiers, I couldn't get them to switch on/off with only 5V input. 

If wireless is a must I'd try the NRF24L01, dirt cheap with surprisingly long range when I created a point to point serial pipe between arduinos: http://www.ebay.co.uk/itm/1-2-4-10x-NRF24L01-2-4GHz-Antenna-Wireless-Transceiver-Module-For-Arduino-UK-/351026325001 - I think its multi-point up-to half a dozen nodes, one on your NodeRed 'master' and the rest connected to the distributed controllers. I plan to get a few more and play with them soon. . 

Ryan.

[Julian Knight]

Cool, thanks Ryan. More stuff added to the list! Thanks for the tips.

Re wireless, like most people, I'm still working through the various options. I've already tried the 24L01's and some other stuff. I thought I'd found the perfect option in the Ciesco SRF based modules but when I've added it all up, they are really still too expensive I think. Also, they are quite poorly documented. My ideal would be something that will go to sleep so I can eke out months from batteries, be cheap (sub £10 per unit) but also be secure! I've already seen quite a bit of activity on my setup from units that aren't in my house! And being a IT security person, I really don't want my home control system hackable!! The Ciesco radios have built-in encryption which is missing from the 24L01's.

Next up on the list to try are the ESP8266 based Wi-Fi units. I'm having a small conversation with Peter Scargill as he seems really keen on these. They are quite powerful controllers in their own right too so it might even be possible to use them without Arduindo's attached.

[ryan...@gmail.com]

No problem, keen to see how you get on. Today I might hack together some code to turn the bed lightstrip into a sunrise alarm clock, these higher density 5050 strips are bright enough to land a plane, so it should work nicely :D

Good points made on the security side. I've embraced LightwaveRF for most of my power control, main lighting, heating controls etc. Woefully insecure...seems little point me getting worried about encrypting other parts now.

Is the power consumption not fairly hefty on those Wi-Fi modules?

[Julian Knight]

Funny, I've been recently thinking about making a terribly overcomplex alarm clock using a Pi, Node-Red, speaker and some LED's! I already have a bedside sunrise alarm clock but it isn't very flexible. In any case, my daughter expressed an interest in getting a new alarm so I started thinking! Always dangerous.

So far, I got as far as setting up a music player on the Pi that can be controlled via a web interface so I can program it. Now I'm just finishing off my web interface for NR which I need for the home hub project anyway so I see these two projects converging.

Security: Well I've got NR only recognising specific ID's for my sensors and switches and the Lightwave & Home Easy switches all have to be paired anyway so there is some security there though obviously anyone with a sufficiently powerful receiver can listen in. The RFXtrx433E is certainly very powerful & I do pick up signals from other houses round about. But there is a difference between that and allowing my node-red and web traffic to leak, especially when those interfaces have significant intelligence about the house such as where things are, if anyone is at home and so on. I wouldn't want someone to be able to hack all the lights off or on or turn the heating up to max while we are away for example. We are in an area with a lot of students so the capability is probably around us! Also, from my work, I'm exposed to some of the worst goings on in the cyber world so it does tend to make me naturally, and rightly(!) paranoid.

Wi-Fi: Certainly they are more power hungry than a simple wireless unit. But on the other hand, having a singe wireless network with higher level access (TCP/HTTP) is certainly interesting. Interesting enough for me to have a go anyway since you can get the ESP units for just a few pounds. It remains to be seen whether the power and transmission distances will be a blocker. Peter Scargill was saying that it only takes a few seconds to start one up and make a connection so it may still be OK for those sensors that only need to be powered up once every 5 minutes. The ESP's seem to use around 250 to 350 mA in action from what I'm being told so that still isn't too bad.

[Mike Biddell]

Julian

dont you just need one of these by your bed??? Then inject at a specific time?? http://www.ebay.co.uk/itm/Rev-Mobile-Wireless-Door-Chime-Radio-Gong-Receiver-433mhz-Up-to-30m-Without-/331519841989?pt=LH_DefaultDomain_3&hash=item4d301f56c5

that's what I'm going to do with RFXCOM

mike

[Julian Knight]

Well it is certainly cheap though the information leaves a lot to be desired.

However, I don't think it will work with the RFXtrx433E. Those and similar units are pre-programmed to deal with recognised wireless api's such as LightwaveRF, Home Easy, X10 and so on. Unless that unit on eBay uses one of the recognised api's, you won't get any data from the bell push nor be able to trigger the ringer.

That is why I've only just got an automatable bell. The Clas Ohlson Nexa range IS compatible with the RFX. I now have mine set up fully. The bell push triggers the ringer directly but also notifies NR. I can also trigger the ringer from NR. NR sends a notification to mine and my wife's mobile phones when the bell push is triggered - using PushBullet. The unit I brought was an LML-710 I think & cost around £20. The Nexa range uses the "AC" setting in the RFX (you will see what I mean when you configure the RFX which you can easily do with an application you can download from RFX), The RFX website has the documentation for download so you can easily see all of the compatible hardware.

This might be a little disappointing. However, the reason is that each manufacturer uses complex proprietary signal timing between their senders and receivers. This is nigh-on impossible to reverse engineer without some significant signals knowledge and hardware. The advantage then of the RFX and similar units (like the TELLSTICK) is that this is already done for you. That, I think, is one of the reasons they are expensive. Thankfully, the firmware is updated fairly regularly with new supported hardware.

[Julian Knight]

Oh, and no! I don't want one anywhere near my bedroom!! :)

Actually, the daylight alarm I have is vastly preferable both to me and my wife. I nearly always wake to the light not to some horrendous klaxon or an alarm, much more relaxing.

On Saturday, 25 April 2015 17:46:56 UTC+1, Julian Knight wrote:

Well it is certainly cheap though the information leaves a lot to be desired.

...

[Dave C-J]

Main thing with ESPx8266xx series is that so far they are not low power in any way... - so not really suitable for battery operation - but are getting more and more capable thanks to people in the community like Pete - so now they can control strings of LEDs (via some FETs) directly etc - which would need power anyway... see - http://tech.scargill.net/esp8266-and-rb-serial-leds/

Or to make it look like the Arduino - or rather use the Arduino IDE ... - https://github.com/esp8266/Arduino

[Julian Knight]

Thanks Dave. I've found a few articles discussing how to reduce power consumption. The simplest is probably just to use one as a serial board and use an Arduino to cut the power when not needed. I've got at least one sensor to make that needs to be always on anyway (to measure the mains power consumption) so that is likely to need mains power anyway. The ESP's do also have a sleep mode though it seems that the lowest you can get just with the ESP on its own seems to be around 50-70 mA and a wake current around 100-300 mA. to go lower, you need an external timer I think, then you can get down to around 10uA.

For the sensors that are only required once every 5 minutes - measuring temperature, humidity & light primarily - it would be nice to have them internally battery powered and not have to worry about them for 12 months or more. There are instructions to do this for the Arduino's, especially for self-build Arduino's since you can do away with the power-hungry Arduino power regulator. Of course, self-build Arduinos can be made for £5 even in low volumes, so double benefit.

The IDE looks promising and might help me get started. I'm not good with C so anything that simplifies things is good ;)

[Mike Biddell]

Julian

my rfxcom arrived this morning. I am going to install the latest "thingbox" distro. After that, how do I install Max's 433 stuff ? is it via command line and NPM install? A few bullet points with paths would be really helpful, if you can find the time.

mike

[Max Hadley]

Mike,

The rfxcom package installs from the command line. Search for node-red-contrib-rfxcom on www.npmjs.com, and the install instructions will be visible on the page. Generally I install in the node-RED user data directory, rather than globally. I'm not sure where the Thingbox sets this, though.

Max

[Mike Biddell]

Thanks Max..... will give it a try

[Julian Knight]

Ha, there you go, Max beat me to it. And it really is that simple.

Only one word of warning, you may get the same problem as me in that the RFX nodes may report as "Not Connected" even when they are.

Also, I found it worth-while running the Windows control software and attaching the RFX to the Windows PC first so you can see the thing in action and reassure yourself that you are receiving/sending what you need. You can make any adjustments and save them to the unit and then move over to the Pi.

[Max Hadley]

Good point - while the set of protocols enabled by default is generally OK, you may need to change it to support some device you want to use, and this is best done from rfxmgr.exe. You can also update the firmware (my test unit is currently at 81, a few versions behind the latest 86). It is also reassuring to see the thing actually works with the supplied software!

Max

[The ThingBox]

On the ThingBox, the userdir is set as follow:

userDir="/root/userdir/"

[Mike Biddell]

Julian

It didn't come with any windows software, do you use  Domoticz ?

mike

[Max Hadley]

Mike

On www.rfxcom.com, go to the 'Downloads' tab and select 'RFXmngr (Windows program)' to download. This is the program that lets you send and receive messages, and change the set of enabled protocols. The manuals, device flasher, and firmware updates are also available here.

Max

[Mike Biddell]

max

got it !!! Not sure I'd have the guts to flash it !!!! It cost too much to brick it !!!!!!

mike

[Julian Knight]

Go for it Mike! I've flashed mine twice now including just a couple of days ago. Though actually, since your's is new, you might not need to. Just check the firmware against the website. I think rfxmgr will tell you the firmware version.

[Max Hadley]

The rfxcom node shows the firmware version - if the connected status gets displayed properly!

Max

[Mike Biddell]

oopppss something has gone wrong? I changed directory in thingbox to /root/userdir/ and did :-

npm install -g node-red-contrib-rfxcom

The following error messages were displayed:-

> seria...@1.6.3 install /usr/local/lib/node_modules/node-red-contrib-rfxcom/node_modules/rfxcom/node_modules/serialport

> node-pre-gyp install --fallback-to-build

node-pre-gyp ERR! UNCAUGHT EXCEPTION

node-pre-gyp ERR! stack Error: ENOSPC, mkdir '/usr/local/lib/node_modules/node-red-contrib-rfxcom/node_modules/rfxcom/node_modules/serialport/build/serialport'

node-pre-gyp ERR! System Linux 3.18.7+

node-pre-gyp ERR! command "node" "/usr/local/lib/node_modules/node-red-contrib-rfxcom/node_modules/rfxcom/node_modules/serialport/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build"

node-pre-gyp ERR! cwd /usr/local/lib/node_modules/node-red-contrib-rfxcom/node_modules/rfxcom/node_modules/serialport

node-pre-gyp ERR! node -v v0.10.36

node-pre-gyp ERR! node-pre-gyp -v v0.5.19

node-pre-gyp ERR! This is a bug in `node-pre-gyp`.

node-pre-gyp ERR! Try to update node-pre-gyp and file an issue if it does not help:

node-pre-gyp ERR!     <https://github.com/mapbox/node-pre-gyp/issues>

npm ERR! seria...@1.6.3 install: `node-pre-gyp install --fallback-to-build`

npm ERR! Exit status 7

npm ERR!

npm ERR! Failed at the seria...@1.6.3 install script.

npm ERR! This is most likely a problem with the serialport package,

npm ERR! not with npm itself.

npm ERR! Tell the author that this fails on your system:

npm ERR!     node-pre-gyp install --fallback-to-build

npm ERR! You can get their info via:

npm ERR!     npm owner ls serialport

npm ERR! There is likely additional logging output above.

npm ERR! System Linux 3.18.7+

npm ERR! command "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "node-red-contrib-rfxcom"

npm ERR! cwd /root/userdir

npm ERR! node -v v0.10.36

npm ERR! npm -v 1.4.28

npm ERR! code ELIFECYCLE

npm ERR! not ok code 0

root@thethingbox ~/userdir #

Any help would be appreciated.

[Max Hadley]

That seems to be saying it ran out of disc space when trying to compile the C language parts of the serialport node. Possibly the file system containing the /user/local/lib directory had filled up. I don't know how the Thingbox sets up its filesystems. Can you provide the output from df, please? As a workaround, try installing locally (without the -g switch) from the node-RED user directory, which is probably in a different filesystem.

Max

[Mike Biddell]

Max

What's the output from the df and where do I find it? I am not familiar with the node-RED directory structure, but presumably from node-RED there is a user folder???

e.g. cd node-RED/user

I am determined to get this working and what I lack in knowledge, I will make up for in persistence LOL !!!!!! 

Mike

[Nicholas O'Leary]

Mike,

run the command "df" in any directory - it gives back a report on the file system structure and space available etc. (this isn't a node-red thing, it's a standard linux command)

Nick

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Max Hadley]

Mike - df ('disk fullness') is a Unix command that reports, for each mounted filesystem, the total capacity and the capacity used for each. It is available from a shell prompt ($ or #) just by typing its name.

A 'normal' installation of node-RED sets the user directory to ~/.node-red where ~ is the home directory of the user who installs it. I have an uneasy feeling the Thingbox doesn't quite work this way. If you start mode-RED, among the verbiage it prints out as it starts is a line which reports the User Directory: that is the place to be to do a local NPM install of (any) extra nodes

Max

[Mike Biddell]

Nicholas and Max

Thank u both..... disk fullness report as below:-

Filesystem     1K-blocks    Used Available Use% Mounted on

rootfs           3023728 2911684         0 100% /

/dev/root        3023728 2911684         0 100% /

devtmpfs          218604       0    218604   0% /dev

tmpfs             222868       0    222868   0% /dev/shm

tmpfs             222868     600    222268   1% /run

tmpfs             222868       0    222868   0% /sys/fs/cgroup

tmpfs               5120       0      5120   0% /run/lock

tmpfs             102400       0    102400   0% /run/user

/dev/mmcblk0p1     57288   14736     42552  26% /boot

[Mike Biddell]

I had a look at thethingbox directory structure. The path seems to be /root/thethingbox/ and the folders available then are:-

node_modules   package.json  settingsttb.js

npm-debug.log  public        thethingbox.js

Mike

[Adam S]

According to your df output your /root partition is full.  The Raspbian image has raspi-conf which has an option to expand the file system.  With thingbox there may be a similar utility, otherwise you will have to manually expand it.

[The ThingBox]

At first boot, a Thingbox expands to the whole SDCard with resize2fs

Script is in root\.auto-expand-scripts (deleted at first boot)

Nicolas.

[Mike Biddell]

Now RFXCOM is installed. I did the NPM install in the node-red directory and as if by magic Max's contributions have appeared in my nodes.

Tried to use rfx-lights. I connected the RFXCOM to the PI USB and sure enough it connected saying "OK (firmware 235)". I then wired the node to a debug node. I then set rfx-lights to receive commands sent to any address. It was at this point I struggled, as there was no output to the debug window. Most of my devices are PT2262, and require undecoded on ?? Does rfx-lights always require a name? Or will it onward transmit any code it 'sees' ?

Any help would be appreciated.

mike

[Max Hadley]

Mike - it looks like you have a problem! The PT2262 is type lighting4, which is not currently supported by the underlying rfxcom library :-( I had a look at it, but the packet data isn't properly documented. There seems to be a 24 bit address (?) followed by a 'pulse timing' value, but it doesn't explain what that does. Can you receive messages from the remote on RFXmngr? If so, that would help immensely. I don't even know what the functionality is - on/off, of dimming, or what. It would be great to get this one fixed if at all possible.

Max

[Mike Biddell]

Max

RFXmgr does receive the remote codes. And from some extreme distances, but only with undecoded ON. I think most cheap Chinese motion sensors and lighting sockets use PT2262 and RFXCOM does receive them in PC mode, just not in node-red.

mike

[The ThingBox]

Investigating a little more, it seems the ThingBox image for the Pi1 does not expand as expected at first boot.

We are fixing this today.
Nicolas.

On Friday, May 1, 2015 at 4:12:57 PM UTC+2, Adam S wrote:

[Mike Biddell]

Ahhhh that explains why the install in the user directory failed

[The ThingBox]

No pb with the Pi2 image.

[The ThingBox]

Here is the fix:

https://s3.amazonaws.com/TheThingBox/TheThingBox-1.5.1-rpi1.zip

[Nicholas O'Leary]

Nicolas - a suggestion: could provide the commands Mike needs to grow his root partition rather than point at a 1.2Gb image, so he doesn't have to start from scratch?

Nick

On 4 May 2015 at 20:19, The ThingBox <theth...@gmail.com> wrote:

Here is the fix:

https://s3.amazonaws.com/TheThingBox/TheThingBox-1.5.1-rpi1.zip

--

[maxime....@digitalairways.com]

Hello,

You can grow root partition with this commands with a TheThingBox (I suppose you work with root):

$ /usr/bin/raspi-expand-rootfs.sh

After that you need to reboot:

$ reboot

When the raspberry is rebooted:

$ resize2fs /dev/mmcblk0p2

Now, you can do a df -h for check your root partition use the all sd card.

You can use raspi-config too. Into raspi-config you have a menu "Expand Filesystem". You can use this way with all raspbian.

Tell me if you have any troubles ...

Maxime

[Mike Biddell]

Thanks Maxime

I'll put those in my Unix command notebook.....which has expanded a lot recently with exposure to this forum !!!!

[Julian Knight]

Hi Max, does that mean that any PT2262 based device will be picked up by the rfxtrx433? If so, that would give yet another low-cost wireless solution to add to the bag of tricks. If that were true, I'd be prepared to get one and do some tests to see if we can tie down the output formats.

On Monday, 4 May 2015 13:02:09 UTC+1, Max Hadley wrote:

[Mike Biddell]

PT2262 signals are just six hex digits e.g. 744d03. They are either received from sensors or can be transmitted. When transmitted to a socket, ON and OFF have a different code e.g. ON = 155157 OFF = 155154. A PT2262 motion or door contact sensor only sends a single code to signify motion detected or door opened, again six hex digits (24 bits).  You can set door contacts and PIRs to any 24 bit value, using jumpers and you resolve local value conflicts by changing the jumpers. 

[Julian Knight]

So if I were to buy one of these:

PT2262 Wireless Transmitter Module (433MHz version)

It would work with the rfxtrx433e?

[Mike Biddell]

Julian

Receiving PT2262 on RFXCOM seems to require undecoded ON and transmission works via lighting 4 (you just set the appropriate 24 bit (6 hex digits)) and then transmit. It controls my burglar alarm perfectly (using RFXCOMGR lighting 4,  I can set ARM, INTELLIGENT, DISARM and PANIC). With the device you specify, I notice there are no jumpers, so I'm not sure how you would set it to a specific code and the set up data  sheets are only available after purchase !!!???? So in theory, node-red could support all this, but not without modification/addition to the RFXCOM libraries. Incidentally, I can send and receive these codes in node-red using RFSNIFFER and CODESEND, but with poor range. Getting it working with RFXCOM would would be great, as it is a wonderful piece of hardware.

Mike

[Julian Knight]

Many thanks for that Mike. Might be worth a punt for only £5 or so. I've got some ESP Wi-Fi modules on the way so I'll give those a go first.

I wonder if it is worth you jumping on the RFX forums to see if they would consider supporting it properly? After all the undecoded On setting is meant to only be for that purpose.

[Max Hadley]

Mike/Julian,

I've been doing a bit of investigation into the PT2262/PT2272 chip set. One of the more useful links I found is http://www.enide.net/webcms/index.php?page=2262-2272-codec which explains how the code is read by the chip and what the transmitted pulse patterns look like. Thinking round the problem a bit, I am feeling my way towards an implementation that would allow node-red-contrib-rfxcom to support them 'gracefully'. My current ideas are:

1. Introduce two new node types, rfx-raw-in and rfx-raw-out. Initially, rfx-raw-in listens for any packet of type lighting4, extracts the data, and outputs a message containing only a property 'raw', which a hexadecimal string representation of the data, between "0x000000" and "0xFFFFFF". This can then be connected to a debug node to 'sniff' the data pattern sent by your sensor, remote control or whatever. When the rfx-raw-out node receives a message with a 'raw' property and no 'payload' property, if the 'raw' property is a hexadecimal string, or a number in the range 0 to 16777215 it transmits the corresponding data. This by itself is enough to allow basic flows to be put together.
2. Introduce a new config node type rfx-raw-dictionary. An instance of this node type is associated with each of the rfx-raw-in and rfx-raw-out nodes. Editing this config node lets you enter one or more associations between a data value (0x0 to 0xFFFFFF) and a topic/payload pair, where both topic & payload are arbitrary strings. The association would work both ways: rfx-raw-in looks up the received data, and if it finds a match, adds the associated topic & payload to the output message along with the raw property; rfx-raw-out looks for a match on both the topic & payload of a received message, and if a match is found transmits the associated data (if no match is found, nothing is transmitted - even if a raw property is also present).
3. I think I should keep the 'address from message topic/always the same address' selection behaviour as in the other nodes for consistency's sake, and because it helps make flows simpler. As now, it is up to the user to enter a sensible address filter, free from typos! (However rfx-raw-out might be able to warn if the filter topic does not exist in the dictionary)
4. It seems like a good idea to allow more than one instance of rfx-raw-dictionary to be used in the same flow, so that dictionaries for different hardware devices which just happen to both use the PT2262 chip can be kept separate. In fact, I don't think it is possible to force a config node to be a singleton. There are some corner cases to consider: what should happen if two dictionaries contain clashing entries (same data but different topic/payload, or vice versa)?
5. It would be nice to make the mere presence of an rfx-raw-in node enable raw reception on the associated RFXtrx433, but this might be a bit over the top. After all, enabling other types of reception is out of scope of node-red-contrib-rfxcom at the moment.

I have been in email contact with Bert, and he has answered a few questions so I'm happier about what needs to be done, but I think I'd have to get a couple of actual physical PT2262 devices to test with.

What do you think? Would this approach work for you? Any suggestions/criticisms/alternative spring to mind?

Cheers,

Max

On Tuesday, 5 May 2015 18:03:12 UTC+1, Mike Biddell wrote:

[Julian Knight]

Well, that seems an impressive piece of thinking Max!

Of course, the "best" solution would be to be able to produce some output that could be sent to Bert for him to add to the firmware for future support!! ;)

Failing that though, your approach seems workable at first sight. It would certainly seem to make the rfxtrx+NR+your nodes into something more generic and powerful for "unsupported" 433MHz transceivers which must be a good thing. It would be great to have another low-cost option. These chips seem to be pretty cheap. Not sure what the power management is like but if we can make multiple £5 transmitters talk to the rfxtrx, we've probably got a winner.

Like the idea of using a mapping dictionary to turn the raw data into something more sensible. One thought though - would it be better to keep the raw nodes even more generic so that they can pick up anything recognisable by the rfx? That way, your raw nodes could be used instead of the rfxmgr software and save us the trouble of swapping wires round if we just want to look at the raw output or send something a bit different.

There might even be a future extension to allow us to send and save mode changes to the rfx? The Windows software is good but the ability to do everything from NR on any supported platform would be really nice. Just a thought.

On Tuesday, 5 May 2015 20:46:08 UTC+1, Max Hadley wrote:

Mike/Julian,

I've been doing a bit of investigation into the PT2262/PT2272 chip set. One of the more useful links I found is http://www.enide.net/webcms/index.php?page=2262-2272-codec which explains how the code is read by the chip and what the transmitted pulse patterns look like. Thinking round the problem a bit, I am feeling my way towards an implementation that would allow node-red-contrib-rfxcom to support them 'gracefully'. My current ideas are:

..

[Mike Biddell]

Max

I think what you are proposing sounds spot on. Item 1) in your proposal will give me almost 100% functionality. Just sniff the code with raw in, whether from a sensor or remote and then use raw in payload into a switch and branch into actions for each code. Although the rest of your ideas are all nice to haves.

It seems to me that if this can be accomplished, RFXCOM will be the ultimate 433 solution. There are so many cheap PT2262 devices ..... transmitters, receivers, alarms, PIRs, light switches, door sensors, fire detectors, relays, door bells..... it's a bottomless pit !!!!

Mike

[Julian Knight]

What sad old men we are getting excited about this stuff!! :)  Love it!

[Dave C-J]

Rather than a config node.... Would it makes sense to consider a generic dictionary node ?
(Though the change node now allows multiple rules so may cover it ??? )

[Max Hadley]

On Tuesday, 5 May 2015 21:42:36 UTC+1, Julian Knight wrote:

Well, that seems an impressive piece of thinking Max!

Of course, the "best" solution would be to be able to produce some output that could be sent to Bert for him to add to the firmware for future support!! ;)

The PT2262 protocol is already fully supported by the RFXtrx433 firmware as the 'lighting4' packet type. The problem is, the mapping between the 24 available message bits and the 'address' and 'command' functions is completely non-standardised across the many devices using this chip, so it can't be decoded in the firmware. However, we can do it in Javascript!

Failing that though, your approach seems workable at first sight. It would certainly seem to make the rfxtrx+NR+your nodes into something more generic and powerful for "unsupported" 433MHz transceivers which must be a good thing. It would be great to have another low-cost option. These chips seem to be pretty cheap. Not sure what the power management is like but if we can make multiple £5 transmitters talk to the rfxtrx, we've probably got a winner.

The PT2262 protocol is supported, but others may not be...

 

Like the idea of using a mapping dictionary to turn the raw data into something more sensible. One thought though - would it be better to keep the raw nodes even more generic so that they can pick up anything recognisable by the rfx? That way, your raw nodes could be used instead of the rfxmgr software and save us the trouble of swapping wires round if we just want to look at the raw output or send something a bit different.

Some confusion here, I think. You can enable reception of 'lighting4' like any other protocol in rfxmngr & the appropriate packets will be delivered when a message arrives. This is not the same as enabling 'undecoded' operation. That is not fully documented, but I think it returns some sort of packet encoding the mark & space times of each received pulse in a transmission. In principle that might achieve what you suggest, but it' would be a bit of a job, and run all the usual risks of an unsupported API.

There might even be a future extension to allow us to send and save mode changes to the rfx? The Windows software is good but the ability to do everything from NR on any supported platform would be really nice. Just a thought.

The underlying node-rfxcom package lets you do that, but I didn't want to complicate the node-RED nodes unduly. You also have to be careful not to wear out the limited-cycle EEPROM used to store the configuration, for example by saving the configuration each time a flow is deployed. There is also the issue that not all packet types can be enabled at the same time, some are mutually exclusive. Since you need a Windows machine to re-flash anyway, I thought I'd leave it out.

I do read the set of enabled protocols when connecting to the RFXtrx433 however: I suppose this could be output to the console.

Max

[Max Hadley]

You could certainly use a change node to achieve a similar effect - but not in both directions, or without duplication if you have more than one rfx-raw node.  My idea was to put all the definitions in one place

[Dave C-J]

Hmm a "swap" node... Or maybe just an extra feature required of the change node...  (Two-way)

(I have no objection to you doing it inside the node - just keen to check of there is more genetic functionality that may be usefully broken out)

[Max Hadley]

Like the idea of using a mapping dictionary to turn the raw data into something more sensible. One thought though - would it be better to keep the raw nodes even more generic so that they can pick up anything recognisable by the rfx? That way, your raw nodes could be used instead of the rfxmgr software and save us the trouble of swapping wires round if we just want to look at the raw output or send something a bit different.

I forgot to say -  you can enable debug output from the underlying node-rfxcom package by setting the environment variable "RED_DEBUG" to a string containing "rfxcom". This includes byte dumps...

Max

[Mike Biddell]

Max

I'm not sure why you want to map groups of codes to functionality??  The user does that for his local system. If I receive A0740C, I know that is my lower hall PIR and hence the actions which flow from that are based on that knowledge, rather than some arbitrary grouping of sensors or mains sockets. My system has a large number of arbitrary codes, but I know what each code is and they are all unique (I change the code physically if there is a conflict). So it is my local understanding which allows me to take appropriate action for each code. Is that what you meant? Or have I misunderstood?

Mike

[Max Hadley]

My thought was you might have for example a set of PiRs which just output a code, and then maybe a remote control which had a fixed code part, and some bits for commands like 'on', 'off', 'set channel' or whatever. It would make sense to keep the dictionaries separate. Just to make it easier for the user

Max

[Julian Knight]

OK, my misunderstanding. Thanks Max. Looks like you already have thought of the important parts.

On Tuesday, 5 May 2015 22:20:28 UTC+1, Max Hadley wrote:

On Tuesday, 5 May 2015 21:42:36 UTC+1, Julian Knight wrote:

Well, that seems an impressive piece of thinking Max!

Of course, the "best" solution would be to be able to produce some output that could be sent to Bert for him to add to the firmware for future support!! ;)

The PT2262 protocol is already fully supported by the RFXtrx433 firmware as the 'lighting4' packet type. The problem is, the mapping between the 24 available message bits and the 'address' and 'command' functions is completely non-standardised across the many devices using this chip, so it can't be decoded in the firmware. However, we can do it in Javascript!

Failing that though, your approach seems workable at first sight. It would certainly seem to make the rfxtrx+NR+your nodes into something more generic and powerful...

 

Max

[Mike Biddell]

oh right.... gotcha..... that does make sense from the clarity point of view. I thought you thought there were reserved blocks of codes for various functions !!!!!!

[Julian Knight]

Wouldn't the correct term be a "mapping" node?

[Julian Knight]

Ah, didn't know that! I'll give that a go when I get a chance as I'm beginning to see some odd results at present. I think I'm picking up some wireless units from other houses but some at least appear to be coming through on "unknown" channels.

On Tuesday, 5 May 2015 22:38:07 UTC+1, Max Hadley wrote:

[Max Hadley]

Actually I think it would be a 'bimap'. While the functionality generalises nicely, the editor UI is a more difficult problem. In this application, it makes much more sense to show a dialogue with two edit controls labelled 'topic' and 'payload'. In a general case, you would have to allow the user to type in a string which might be JSON or something, and have a means of specifying if the string should be parsed. Icky!

[Max Hadley]

 

I'm trying to order a couple of the cheap PT2262 modules from Hobby Components, but Paypal seems to be down (probably the battery has gone flat!)

On reflection, I think the *-raw-* nodes should be *-PT2262-* to avoid the sort of confusion which arose yesterday!

Max

[Max Hadley]

Ordered!

[Mike Biddell]

Max

Been having a play with RFXCOM and RFXMGR. I have noticed something rather strange ???? I can send the lighting 4 codes (PT2262) to control my burglar alarm, but using the burglar alarm remote, they are not received by RFXCOM??? Is there a bug in lighting 4 receive or a restriction on incoming codes. However, lighting 4 receives all of my door sensors and PIRs.

Bewildered of Tamworth

Mike

[Max Hadley]

That's odd. It might be because the pulse timing is marginal. The PT2262 uses a resistor to set the basic time interval from which all the pulses are generated, and there is no guarantee all devices using the chip have the same value. Lighting4 seems to use a base of 350us, which it claims covers 'most' devices so I suppose it is possible that the remote control timing is out just too much for rfxcom to decode but close enough for the alarm box to cope. It isn't clear to me if the receive pulse timing can be changed, but it looks as if the transmit pulse can. I've started work on the lighting4 mods, so maybe at the weekend I'll have a look at what the rfxtrx433 actually transmits (luckily I have an RF spectrum analyser & digital scope to hand!) However I don't think I'll be able to receive a signal from Tamworth!

Max

[Mike Biddell]

Max

Marginal timing was one thought which crossed my mind. The codes in question are received by my Ninja Block, so there must be some way of building PT2262 timing tolerance into the software and RFXCOM must be a little intolerant. I dont know how the RFXCOM software works, edges or bit banging, but perhaps its pulse width acceptance for lighting 4 could be mitigated !!!

Dont know where u live Max, but transmitting from Tamworth could be a bit ambitious.

Less Bewildered of Tamworth

Mike

[Mike Biddell]

The plot thickens and supports the marginal timing theory. I have transmitted exactly the same PT2262 codes from my Ninja Block, rather than the alarm remote, and RFXCOM detects them every time. Also if I transmit the same codes from RFXCOM, it detects its own transmission. Therefore, the timing from the alarm remote is a bit marginal, and Ninjablock has sufficient tolerance to receive the signals,  but tidies up the timing on re-transmission. 

I suggest therefore on the balance of probability, that others may find some PT2262 devices do not register with RFXCOM receive, due to timing issues. So, Max..... dunno whether you can work some magic to relax the timing tolerances a wee bit !!!!! Incidentally, if I run RFSniffer from within node-red, it detects these same codes !!!! So comparison of the RFSniffer code with the RFXCOM code may reveal the trick!!!!

Velly intelesting glass chopper !!!

Mike

[Julian Knight]

More confusion from me.

I have a Home Easy based PIR unit that has been working perfectly. But since I got my Nexa doorbell (which signals on AC), I am now getting 2 signals for each trigger of the PIR, one on AC with a Topic of AC/0x0000A9F8/2 and one on Home Easy with a Topic of HOMEEASY_EU/0x000081C0/2.

This threw me for ages since I'd turned off the debug messages for the PIR and I wasn't triggering anything based on it. So when I started seeing an "unknown" signal on AC, I assumed I was picking up a new device from a neighbour.

Anyone else seeing anything like this on the RFXtrx433E? I did update the firmware when I got the doorbell so I wonder if that is causing this.

[Julian Knight]

Even more bizarre, the two messages have different RSSI levels. The HE message has an RSSI of 3 but the AC message has an RSSI of 6.

[Max Hadley]

Bizarre! I can only surmise that something is listening to events it shouldn't do - unless the PIR is triggering the doorbell to transmit. Are both the addresses known to you?

[Max Hadley]

Can you turn on RED_DEBUG and see if the rfxtrx is sending two message packets, please? Dump would be nice!

Max

[Julian Knight]

The AC identifier isn't known to me. The HE identifier is the one I've been using fine.

Dump:

9 May 15:30:03 - [info] [rfx-lights-in:Listen to RFX: Lights] connecting to /dev/ttyUSB0
9 May 15:30:03 - [info] serial port /dev/ttyAMA0 opened at 115200 baud 8N1
[rfxcom] on /dev/ttyUSB0 - Sent    : 0A,14,00,00,88,D8,D7,03,00,00,00
[rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,00,00
[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,6D,30,01,00,D8,30,01,59
[rfxcom] on /dev/ttyUSB0 - Sent    : 0D,00,00,01,00,00,00,00,00,00,00,00,00,00
[rfxcom] on /dev/ttyUSB0 - Sent    : 0D,00,00,02,02,00,00,00,00,00,00,00,00,00
9 May 15:30:09 - [info] [rfx-lights-in:Listen to RFX: Lights] connected: Serial port /dev/ttyUSB0
[rfxcom] on /dev/ttyUSB0 - Received: 0D,01,00,02,02,53,F0,00,02,2C,00,01,02,00
[rfxcom] on /dev/ttyUSB0 - Received: 0B,11,00,00,00,00,A9,F8,02,01,0F,60
[rfxcom] on /dev/ttyUSB0 - Received: 0B,11,01,01,00,00,81,C0,02,01,0F,30
[rfxcom] on /dev/ttyUSB0 - Received: 0A,52,01,02,30,01,00,D8,30,01,49

[Julian Knight]

I should have said that I triggered the PIR which you can see straight after the second [info] message. Typically the AC message comes immediately before the HE one.

The PIR isn't triggering anything at present & has never been connected to the doorbell

[Max Hadley]

That log says the RFXtrx433 is sending two packet messages to the serial port, presumably in response to the same received radio transmission. The first one is the AC message with identifier 0xA9F8, the second is the HOMEEASY_EU with identifier 0x81C0. When you got the doorbell, did you enable AC reception on the RFXtrx, assuming it was previously disabled? I suspect that the radio is transmission is ambiguous, i.e. it could be interpreted as either message, so that if both are enabled it sends both packet messages. When I get a chance, I'll send both messages from my RFXtrx & take look at the actual transmitted signals (not just now, got to go do the ironing!)

Remember that you can use the pattern matching option of the rfx-lights-in node to match on just a protocol type if you want, 'AC' or 'HOMEEASY_EU' should be enough to filter out the unwanted response. Any prefix match works, so you could use HOMEEASY_EU/0x000081C0 if you want just the one device.

Max

[Julian Knight]

Hi Max, thanks for that, hope the ironing went well! I know the feeling. I've had to spend most of the day clearing the hall and landing ready for the decorators on Monday. Got right in the way of me wiring up my new BMP180 pressure/temperature sensor!! Thankfully, that was pretty easy and the test Arduino is now sending the data nicely to Node-Red.

You are correct that I turned on AC when I got the doorbell. I didn't really want to change my flows since I have things nicely set up to receive any input from any device, normalise the data and then filter on known devices. I can still do that so it isn't really an issue, just confusing. I'll have to add in a filter for known unknown devices along side the known and unknown! :}  If I filter at the reciever node, I would have to keep adding receivers each time I added a new device. Ultimately, I want to change my flow so that I can keep the definitions for known devices in MongoDB and read on startup. So I want to be able to normalise and filter programatically. I'm nowhere near that yet but I don't want to forget it. Have you had any thoughts along those lines?

[Max Hadley]

Well, it was a nice theory while it lasted. However, the transmitted pulse pattern for the two packets is quite different:

The top trace is HOMEEASY_EU/0x000081C02/2 : On

The bottom (reference) trace is AC/0x0000A9F8/2 : On

I don't know why you are seeing this effect, maybe it is a bug in the firmware? Try contacting sup...@rfxcom.com & see if Bert can enlighten us!

Regarding your question about programmatic filtering of messages, We had a discussion on the list about this subject in the earliest days of the rfxcom nodes. The general feeling was to avoid too much complexity in the UI. The commonest task - listening to messages from one specific address - is easy, while more complex things are still possible. Since that time, additional 'core' nodes have been added that let you route & change messages without writing any Javascript, and are also more general, which I think confirms our original approach.

If you are running on a platform with I2C support, the node-red-contrib-bmp085 node also works with bmp180 sensors. I recently contributed an update to this node to add user-selectable measurement units and optional sea level correction of barometric pressure.

And the ironing is all done!

Max

[Max Hadley]

You should check if you see the double messages with rfxmngr as well

Max

[Julian Knight]

Thanks again Max.

I need to plug the rfx into my laptop and check it on the mgr software. Then I can raise it as an issue if needed.

Re programmatic definition of devices. Your suggested approach is the one that I'd assumed anyway. At some point I need to generalise my flow so that I can pick up the definitions from a db but while I only have a few devices connected it isn't my top priority.

Pleasingly, to get the bmp180 pressure data showing up on my home hub web page simply meant changing the arduino code to output the data in a std format I'd already decided on. Then all I needed was to add a span on the page with an ID with a std naming convention. I'd already generalised everything else and it just worked! The page gets the data and updates dynamically thanks to MQTT over websockets.

I've got the bmp180 on an Arduino. There are too many complexities on the Pi for my liking and in any case I have a Ciesco slice of radio plugged in that, annoyingly, occupies all of the GPIO slots.

[Max Hadley]

Mike,

I now have one of the Hobby Components PT2262 modules here in captivity. I have hooked it up to a 4.5V supply & a pushbutton, and I can reveal that it is not received by my RFXtrx433. Investigation with the spectrum analyser and digital scope reveals that (in addition to transmitting an RF bandwidth somewhere around 500kHz!) the pulse timing is not close to 350 microseconds. It's more like 480 microseconds. I grabbed a transmission from the PT2262 module as a reference, and used rfxmngr to transmit the same code, adjusting the timing until the two lined up: the closest match was with the timing parameter set to 488 microseconds.

The bottom trace is the PT2262 module, the top trace is the RFX with timing set to 488 microseconds.

The timing resistor on this module is 4.7 Mohm, which should give a pulse around 570 microseconds, according to the tiny graph in the chip data sheet, but that is within the sort of tolerance I'd expect. If I get a chance, I'll swap it for a 3.3 Mohm resistor and see what happens.

In other news, work on the rfx-PT2262 nodes is progressing, slowly...

Max