Since NetHome now officially support the Telldus Tellstick, the project now also has its own page on Telldus site for 3:rd party applications - check it out on here. Currently I am slowly moving documentation to the new site - a bit boring, but I guess it has to be done...
Hi,
ReplyDeleteThis is indeed very nice and it is working fine, I managed to get the TellStickDuo working with OpenNetHome in a RPi.
What would be nice to have in addition in the settings for the TellStickDuo is the possibilty to select what protocols it should support from OpenHomeServer perspective, i.e. the same setting as you have for the audio device. This would then allow you to configure a nice distributed system with various tranceivers supporting a selective range of protocols for each.
Also missing in OpenNetHome is support for Oregon sensors (currently supported by TellStickDuo). I think many users have Oregon sensors so this would make a great enhancement.
Best regards, Walter
Good feedback. Possibility to separately configure which protocols are received and transmitted is now implemented in the Tellstick-Item and available in the Nightly build. But why do people use Oregon scientific sensors? They are almost four times more expensive than the UPM-sensors! Oh well, maybe I will look in to that, I have heard requests about support for them from others as well...
ReplyDelete/Stefan
"Possibility to separately configure which protocols are received and transmitted"
ReplyDeleteWorks excellent, thanks
Regarding Oregon:
+ much better reach, much more accurate, looks better
- more expensive, changes id when battery replacement
Still worth it
"changes id when battery replacement"
ReplyDeleteWow. That's a real show stopper for me. So far, I've gone with UPM, but they have lousy range. Was thinking of putting Oregon sensors in the farthest rooms, but will have to think again.
No Oregon support in NetHome is also kind of a show stopper. Didn't know that.
Ok, ok... Walter speaks so kindly about the Oregon, so I actually implemented support for it now. The implementation is still a bit rough around the edges, but it should work (I always get confused by this Manchester encoding). In the current implementation you can choose if you want to identify the sensor with the sensor id (which changes on power loss) or on the channel, which is set with a switch on the sensor. It raises an alarm on low battery just like the UPM. It is in the nightly build
ReplyDelete