Hi All!
I tried to read through all the information I could find on the Internet about these two products. I seems that both could suit my requirements, but I couldn't find a details comparison. Can you help my with the advantages of the the rfxtrx433? It seems that Telldus' Live! service and a more active community would be an advantage of the Duo
any advice is greatly appreciated
tamas
Advantages of RFXtrx433 over Tellstick Duo?
Moderator: b_weijenberg
Re: Advantages of RFXtrx433 over Tellstick Duo?
In my opinion the Tellstick Duo should be avoided at all cost if possibe. The RFXtrx433 has longer range, supports the most devices by far, has way better support, and it receives firmware updates more often.
The RFXtrx works with different software or gateways, where Tellstick is mainly supported by their own software (which isn't that good). For the RFXtrx433 you can even use it's "own" specialized software, Domitcz.
Since the RFXtrx433 is available, I can't think of a reason why to buy the Tellstick Duo at all.
The RFXtrx works with different software or gateways, where Tellstick is mainly supported by their own software (which isn't that good). For the RFXtrx433 you can even use it's "own" specialized software, Domitcz.
Since the RFXtrx433 is available, I can't think of a reason why to buy the Tellstick Duo at all.
HSPro 2.5.0.60, X10 CM11, Z-wave Aeon Stick2, RFXCOM, Script Connector, BT connector, DI Connector, DooNetwork, HSTouch, Squeezebox plugin, iTach WF2IR & GC-100-6 with UltraGCIR, BLicon, DenonAVR, WebcamXP, Jon00s MaxiBee and Webpage builder
Re: Advantages of RFXtrx433 over Tellstick Duo?
I would fully agree that the RFXtrx is a better choice even if the supply problems would not be there. I also agree to all arguments about quick response, range, support, firmware updates, number of supported device types etc, all in favor of the RFXtrx.
As a software developer integrating these types of devices (I am the author of the EventGhost plugin's for RFXtrx and the TellStickDuo) I personally think that the RFXtrx protocol is working much better, and most important, gives by far a much more stable solution than the Telldus api.
One could argue that the api approach would simplify the development since the RFXtrx has a typical serial interface that needs to be maintained for almost each new device that is being added. In one way this is true because an api could make an integration more device independent. When support for a new device type is introduced, there should typically be no need to make any modification of the existing integration (unless the device would bring completely new functionality). But if the cost is an unstable solution that needs to be monitored and eventually restarted using various tricks, I would prefer to make new updates more frequently and keep a good control.
Since the first day I put the RFXtrx into operation (24/7/365) it has not failed one single time! I had some bugs in my implementation earlier but the device and the connection to it never failed.
Personally I would not be very keen in having my house automation in the cloud. Just look at the numerous problems people are experiencing. On top, the dependencies, today and what eventually will come in the future. Having the house automation in the cloud is for sure a prime target for a pay service.
Instead I believe in having the control 'in house', fetching or publishing data that I decide about, allowing just myself and family remote access and utilizing the small devices becoming so popular now a days (like the Raspberry Pi).
Best regards, Walter
As a software developer integrating these types of devices (I am the author of the EventGhost plugin's for RFXtrx and the TellStickDuo) I personally think that the RFXtrx protocol is working much better, and most important, gives by far a much more stable solution than the Telldus api.
One could argue that the api approach would simplify the development since the RFXtrx has a typical serial interface that needs to be maintained for almost each new device that is being added. In one way this is true because an api could make an integration more device independent. When support for a new device type is introduced, there should typically be no need to make any modification of the existing integration (unless the device would bring completely new functionality). But if the cost is an unstable solution that needs to be monitored and eventually restarted using various tricks, I would prefer to make new updates more frequently and keep a good control.
Since the first day I put the RFXtrx into operation (24/7/365) it has not failed one single time! I had some bugs in my implementation earlier but the device and the connection to it never failed.
Personally I would not be very keen in having my house automation in the cloud. Just look at the numerous problems people are experiencing. On top, the dependencies, today and what eventually will come in the future. Having the house automation in the cloud is for sure a prime target for a pay service.
Instead I believe in having the control 'in house', fetching or publishing data that I decide about, allowing just myself and family remote access and utilizing the small devices becoming so popular now a days (like the Raspberry Pi).
Best regards, Walter