Working: Telldus 2.1.2 on Tomato USB (Native Toolchain)
Posted: Fri Mar 17, 2023 9:45 am
Hello all!
This is not really an a help request as such, but rather a thread to let you know that I'm working on getting my Tellstick-duo work with my ASUS RTN-16 router.
My setup is (or used to be anyway):
Tellstick duo in ASUS RTN-16 router running Tomato USB, placed in the center of the house
USB-IP on router to basement server with Sabayon-Linux
telldus-core (with some minor extra-hacks) on linux server
tellprox on basement server to have my own "Telldus-live"
remotestick on my android tabs pointed to my local Telldus-live server (have a few tabs mounted around my house)
NexaHome (via freeNX) on my basement server so that I could set up some rules
telldus-controller (home made logging application that will replace NexaHome)
extra-bebug-client-thread
This was all going just fine, until i hit some annoying bugs that made everything go bananas every other day. One problem turned out to be that the telldus-core client library had a bug that hung the communication thread once in a while. Strangely enough this never happened to tellprox-client and after some bread-crum debugging i figured out that it probably wasn't using the telldus-lib. The other clients took turn to hang (and sometimes segfault). After some heavy research I managed to track down the problem to the socket-communication of the telldus-core client lib. I also found some code that looked like misuse of dynamic pointer casting (when implementing a virtual tellstick) but since this wasn't my area of expertise (havent figured out autoptr yet either) i never figured out exactly what was happening, and I couln't be completely sure that my extra-features wasn't the problem. Then, early this year i found that the telldus-git repository hade made some progress and decided to switch to that. This was just before 2.1.2 was out and now most of my problems with the hanging and segfaults disappered.
After that, USB-IP started to be a pain in the ass with regular segfaults, dropped connections, kernel errors and all kinds of funny things going on. Since USB-IP on the router side has made no progress lately (while on the desktop it changed a lot) there may be some incompabilities on that side, but on the other hand the new telldus-core lib could do some strange things to.
The fixes I added to telldus-core?
Well, lets see...
First, I wasn't happy with the way groups were handled. I introduced a new state that i called "unknown" and made sure that for groups with a mix of "on" and "off" they were reported as "unknown".
Secondly, i introduced a virtual tellstick that could help me feed extra signals into the system. (I also have a one-wire temperature measurement system and would like to have all sensors available)
I also made an application that I call telldus-controller based on the tdtool application. My idea was that this controller would be used as a gui-less logic-interface that triggered events based on registetered events. Since it's supposed to run without gui I was thinking about storing logic rules in a database that could be changed from a web-page. As a first step i implemented functionallity to act as a database logger that automatically stored all registered events in a mysql-database.
The idea with the controller was that I would have different "modes" as for example "Home", "Away", "Sleeping" etc. When entering a "mode" different events should be triggered. Modes could automatically hand over to other modes etc. Now, there are applications like this available but none of them fits the requirements of running on a router. For example SwitchKing and NexaHome requieres Windows or Java (more or less). Another novelty would be that everything could be controlled by regular nexa-light switces or via android-remotestick. For example, I have a Nexa-switch mounted near my front door and pushing that before stepping out enters away mode.
So, Now I decided to finally compile telldus-core for Tomato USB and put as much as possible in my router....
So far I have set up three different toolchains, optware, openwrt, and one from ddwrt. With the toolchain from openwrt (or perhaps ddwrt) I actually managed to build the program, but only to have it segfault before startup. Now I'm struggling with the optware toolchain.
Some of my experiences from cross-compiling telldus-core (mostly optware since that's what I use for all other programs on my router)
* cmake and cross-compiling, *sigh*
* tr1/memory isn't available by default in uclibc++, and while you could use the boost version this seems to create a lot of include errors and I will need to package that with my application later.
* wchar isn't available by default, I manged to add this to uclibc++ which forced a recompile of everything else already built. If this is the case, then I will either have to link statically in the end (if all libs are available)
* argp is part of gnulibc but not uclibc and while it's available as a break-out package it's not part of the optware regular dist so I will probably have to make it separately and put it somewhere.
* optware compiles ddwrt-target (which is used by tomato) without mips32 flag so code should be compatible with most routers and boost-lib had an inline-assembler bug that tried to use mips2-instructions in mips1-mode so I needed to add a hack to switch the processor-setting to mips2 on the fly.
Right now I'm struggeling with two compile problems:
1) argp is still missing...
2) /.../Strings.cpp:103: fel: "transform" was not declared in this scope
I'll let you know what happens.
This is not really an a help request as such, but rather a thread to let you know that I'm working on getting my Tellstick-duo work with my ASUS RTN-16 router.
My setup is (or used to be anyway):
Tellstick duo in ASUS RTN-16 router running Tomato USB, placed in the center of the house
USB-IP on router to basement server with Sabayon-Linux
telldus-core (with some minor extra-hacks) on linux server
tellprox on basement server to have my own "Telldus-live"
remotestick on my android tabs pointed to my local Telldus-live server (have a few tabs mounted around my house)
NexaHome (via freeNX) on my basement server so that I could set up some rules
telldus-controller (home made logging application that will replace NexaHome)
extra-bebug-client-thread
This was all going just fine, until i hit some annoying bugs that made everything go bananas every other day. One problem turned out to be that the telldus-core client library had a bug that hung the communication thread once in a while. Strangely enough this never happened to tellprox-client and after some bread-crum debugging i figured out that it probably wasn't using the telldus-lib. The other clients took turn to hang (and sometimes segfault). After some heavy research I managed to track down the problem to the socket-communication of the telldus-core client lib. I also found some code that looked like misuse of dynamic pointer casting (when implementing a virtual tellstick) but since this wasn't my area of expertise (havent figured out autoptr yet either) i never figured out exactly what was happening, and I couln't be completely sure that my extra-features wasn't the problem. Then, early this year i found that the telldus-git repository hade made some progress and decided to switch to that. This was just before 2.1.2 was out and now most of my problems with the hanging and segfaults disappered.
After that, USB-IP started to be a pain in the ass with regular segfaults, dropped connections, kernel errors and all kinds of funny things going on. Since USB-IP on the router side has made no progress lately (while on the desktop it changed a lot) there may be some incompabilities on that side, but on the other hand the new telldus-core lib could do some strange things to.
The fixes I added to telldus-core?
Well, lets see...
First, I wasn't happy with the way groups were handled. I introduced a new state that i called "unknown" and made sure that for groups with a mix of "on" and "off" they were reported as "unknown".
Secondly, i introduced a virtual tellstick that could help me feed extra signals into the system. (I also have a one-wire temperature measurement system and would like to have all sensors available)
I also made an application that I call telldus-controller based on the tdtool application. My idea was that this controller would be used as a gui-less logic-interface that triggered events based on registetered events. Since it's supposed to run without gui I was thinking about storing logic rules in a database that could be changed from a web-page. As a first step i implemented functionallity to act as a database logger that automatically stored all registered events in a mysql-database.
The idea with the controller was that I would have different "modes" as for example "Home", "Away", "Sleeping" etc. When entering a "mode" different events should be triggered. Modes could automatically hand over to other modes etc. Now, there are applications like this available but none of them fits the requirements of running on a router. For example SwitchKing and NexaHome requieres Windows or Java (more or less). Another novelty would be that everything could be controlled by regular nexa-light switces or via android-remotestick. For example, I have a Nexa-switch mounted near my front door and pushing that before stepping out enters away mode.
So, Now I decided to finally compile telldus-core for Tomato USB and put as much as possible in my router....
So far I have set up three different toolchains, optware, openwrt, and one from ddwrt. With the toolchain from openwrt (or perhaps ddwrt) I actually managed to build the program, but only to have it segfault before startup. Now I'm struggling with the optware toolchain.
Some of my experiences from cross-compiling telldus-core (mostly optware since that's what I use for all other programs on my router)
* cmake and cross-compiling, *sigh*
* tr1/memory isn't available by default in uclibc++, and while you could use the boost version this seems to create a lot of include errors and I will need to package that with my application later.
* wchar isn't available by default, I manged to add this to uclibc++ which forced a recompile of everything else already built. If this is the case, then I will either have to link statically in the end (if all libs are available)
* argp is part of gnulibc but not uclibc and while it's available as a break-out package it's not part of the optware regular dist so I will probably have to make it separately and put it somewhere.
* optware compiles ddwrt-target (which is used by tomato) without mips32 flag so code should be compatible with most routers and boost-lib had an inline-assembler bug that tried to use mips2-instructions in mips1-mode so I needed to add a hack to switch the processor-setting to mips2 on the fly.
Right now I'm struggeling with two compile problems:
1) argp is still missing...
2) /.../Strings.cpp:103: fel: "transform" was not declared in this scope
I'll let you know what happens.