As usual I cannot test all variants. I have tested with the THGN132N which is a thermometer/humidity sensor. I have however added code for the THGR122NX, THGN123N, THGR810 and THGR810 temp/hum sensors, the THN132N, THR238NF and THWR800 temp only sensors, the WGR800 wind sensor, the RGR968 rain sensor and the BTHR968 temp/hum/pressure sensor. The support for those is a bit more theoretical, I have implemented it according to specifications, but have not tested them. Oregon Scientific also have three versions of the protocol: 1.0, 2.1 and 3.0. I have now implemented the 2.1 version. 3.0 would be possible to add, but again I don't have any sensors so, that would be a bit too theoretical implementation and I don't know how commonly used it is. Implementation is available in the nightly build.
Dear Stefan,
ReplyDeleteThanks, the Oregon support seems to work
Maybe only me, but I can only get Oregon to work with the AudioProtocolParser, not with the TellStickDuo...
Anyway, I have a couple of THGR238N and THGN132N and they are all received fine. Also an old RGR126 rain gauge is detected without problem.
...forgot to mention but of course, the TellStickDuo does normally detect Oregon sensors when used together with Telldus Center
ReplyDeleteYou were so right, a nasty little bug (in my code) prevented NetHome from seeing Oregon sensors via Tellstick. It is now corrected in the nightly build.
ReplyDelete;) Works fine with Oregon now, thanks
ReplyDeleteBest regards, Walter
First, thank you for a really nice home automation system, have only used it for a couple of hours but looks really promising.
ReplyDeleteSecond, a question, how hard is it to add support for other temperature sensors? I am testing two different ones at home and one of them, a Proove TSS320, is not working with NetHomeServer but works with Telldus Center.
@Edward: Actually, the TSS320 uses the FineOffset-protocol, so it is supported now when I have added FineOffset
DeleteThanks! I am constantly adding support for protocols, currently I am working on the FineOffset-protocol. If it is hard or not depends a bit on if you find documentation for the protocol and how used you are to writing this kind of code. Basically you have to write a small state machine which is fed with pulse lengths, and has to decode the protocol from that. You can look at the code for the existing decoders at: https://github.com/NetHome/Coders/tree/master/src/main/java/nu/nethome/coders/decoders to get an opinion. Personally I think it is a bit like sudoku for grownups ;-).
ReplyDeleteHi Stefan,
ReplyDeleteDo you support X10Port in previous version for CM12 or CM11 A .Please add X10Port to this version too.!
Regards
Marcelo
Hi Stefan,
ReplyDeleteVery good to hear that you are working to add FineOffset-protocol to work NHS. As soon as this option is available, let us know!
/Lassi
@Marcelo: My Cm12 broke so I cannot test X10 any more. I did not really think anyone still used X10, so I removed support for that in 2.0. Do you just want to test it, or are you really using it with NetHomeServer? I could try to add the support again, but it would be some work...
ReplyDelete/Stefan
Hi Stefan,
DeleteI was looking for a solution which can handle my philips Hue Bridge (it's ok) but my CM15 too, with my 3x AM12, (and possibly, later, use my CM15 to control other devices). Would it be easy for me to do the work, with your instructions ? thanks for answer
Hi, I dropped support for X10 when my CM15 broke and I could no longer test it. I did not think anyone still used it. If you will help me test it, I could try to get the code back in, if you can code you could perhaps help in finding problems in it. Register to the forum (http://forum.opennethome.org/) and we can continue the discussion there.
Delete