So, now I have completed (and refactored) the NexaSmokeAlarm-item. I added the ability to actually trigger the alarm via the NexaSmokeAlarm-item too. I also added a "self learn"-function for the address of the smoke detector. Each detector have its own unique address, and by activating the "learn mode" on the home item and then manually triggering the alarm by pushing the test button on the smoke detector, the NexaSmokeAlarm-item learns the address from the alarm.The protocol decoder/encoder and the NexaSmokeAlarm-item are available in the nightly build. One cation - never rely on NetHomeServer for performing any real fire alarm functions. The smoke detectors provide the real alarm, the NetHomeServer can simply provide additional features when the alarm goes off.
Nice addition to the list of supported devices.
ReplyDeleteBtw, any plans to add support for Tellstick? Kind of nice product, a bit lower barrier of entry than hacking your own receiver...
Also, I just today got a wireless energy meter made by WH Mandolyn (brand name ESIC), I suspect that it uses 433.92 MHz, but it doesn't say anywhere. What do you suggest being the best way to establish this? Would a hacked UPC temp meter do the job?
Would be kind of nice to log/graph energy data, just like you do with temperatures...
Finally, any plans for logging to SQL databases? Temps and energy data is kind of nice to have in an SQL db, for later analysis, uploading to Pachube or Google Powermeter etc.
Decoding data from a wireless power meter is pretty high up on my todo-list. Unfortunately the ones I have seen use FM-encoding of the data signal (on the 433.92MHz band), making simple UPM-receivers useless (they use AM-OOK). I guess one way would be to open the receiver and find the decoded digital signal and use that, that would probably work.
ReplyDeleteThis being a hobby project I have basically built things I need (or people have asked for) and I haven't used Tellstick. When the Duo comes out, I might reconsider but it is some work and I don't think my protocol encoders/decoders would work on it.
I intentionally avoided dependencies to databases in the design, but it would be pretty simple to write a database-logger-Item which could log values from specified sensors. Connections to Pachube and Google Powermeter would be great too - so much fun to do and so little time!
/Stefan
Re available time and possible projects to dive into - couldn't agree more..
ReplyDeleteMight crack the UPM wireless powermeter open to see what it contains, will let you know what/if I find.
Hello!
ReplyDeleteNice job.
One question (maybe a bit OT)
The protocolAnalyzer can be used with a CUL 868MHz to read / reproduce a RF remote control signal?
Thank you
Well, almost - but not really. The ProtocolAnalyzer allows you to configure the reception frequency, so you can configure it to 868MHz. Unfortunatly, the CUL have not been very good at reception of these OOK-modulated protocols. Transmitting on 868MHz is not possible with my current CUL firmware. The 868MHz band has a limitation on how long time you may occupy the band, and my firmware have not implemented this limitation, so I hardwire transmission to 433MHz. But - the firmware is open source, so you can actually modify it so it transmits on the 868MHz band...
ReplyDelete/Stefan
Hello Stefan,
ReplyDeleteFirst of all, thank you for the answer.
About the 868 problem, it's a pity, almost all protocols I'm searching for use the 868 band, and it would be an amazing tool one that could "record" and "replay" any RF remote in a house, with or without the need of understanding the protocol.
Obviously, if you understand the protocol you can do more things that just "repeat" the behaviour. But for some devices it's enough to learn and repeat. (on/off lights, up/down blinds, open/ close garage doors).
Unfortunately for me, I don't have the enough knowledge about bands, modulation and frecuency to be able to implement a firmware for the CUL. I'm a mathematician that is an enthusiast of authomation stuff :) althought I'm trying to learn as many things as I can but I have the feel that always are more things out there :(
Any ideas about where I can start to digging?
Again thank you very much for share your knowledge :)
/Gabriel
Hi! I'm trying to get an Arduino to react to the KD-101 LA smoke detector but I can't find any information on the protocol it uses. I would be a very happy man if you could share how the protocol works with timings and codes!
ReplyDeleteCheers!
/Lars
Of course Lars. My mail address is on the "Current state page" (http://wiki.nethome.nu/doku.php/nethomeservercurrentstate). Send me a mail (Swedish works fine), and I can give you the information I have regarding the protocol.
ReplyDelete/Stefan
Lars, did you manage to get KD-101 working with the Arduino?
ReplyDeleteI haven't had time to work on it actually :/ But I have learned that (mine atleast) KD-101 triggers falsly too often. It was so bad that I had to disconnect them from eachother. I have 6 of them in my house.
ReplyDeleteThanks for the prompt reply. Probably KD-101 is not the most robust device because it's so cheap... I'll try to figure out how Arduino can interact with the KD-101 at some point.
ReplyDeleteCool, post back here if/when you make any progress. If you give me your email I can send the source i got from Stefan (NetHomeServer)
ReplyDeleteI'm not 100% sure but it looks like FA12RF is same device as KD-101. I found Arduino code from the GitHub which seems to support FA12RF (https://github.com/jcw/jeelib/tree/master/examples/RF12/ookRelay2).
ReplyDeleteI think I will try some day does that code work with the KD-101 or not...