My forum

Hi,
I managed to port telldus-core 2.1.1 to OpenWRT.

Now my Tellstick Duo is at least able to receive data from the sensors, when connected to my Buffalo WZR-HP-G300NH which runs OpenWRT.

Because it seems that there is some general interest in using a more recent telldus-core with OpenWRT, I'm planning to publish my patches anyway - even if those are are not too pretty currently (one reason is that I haven't used Cmake ever before..)

However, there is one showstopper which prevents me from taking the tellstick to "production use". Also, I'd like to resolve that before releasing my changes to anyone.

The question is related to writing to the configuration files. There seems to be two config files, /etc/tellstick.conf and /var/state/telldus-core.conf, and there are routines which write to both of these (see service/SettingsConfuse.cpp).

I'd like to know how often these files are written into? And in what situations?

Why both files may be overwritten by service/SettingsConfuse.cpp? I thought that /etc/tellstick.conf should be a read-only config file.

Writing to the filesystem should be avoided on embedded devices which might have only ordinary, fixed flash chips for the filesystem. I want to avoid excessive writing, so that the flash wont burn out. Code which never writes to the flash is of course even better.

So, is it possible to disable the writing code completely, or would there be bad side-effects if I do so?

/etc/tellstick.conf is never written if not using the API functions to do so. For a headless system only using tdtool its fine to have it readonly.

/var/state/telldus-core.conf is rewritten on every state change. It is fine to map this to a tmp filesystem or ramdisk. The drawback is that the state is lost on reboot. This is probably ok.

You can use or code for 2.0.4 as a base for your patch. The way to build it should be fairly similar.
https://dev.openwrt.org/ticket/9062

Short instructions for building telldus-core 2.1.1 for OpenWRT (assuming that the OpenWRT buildroot has been set up (instructions are in the OpenWRT wiki if needed)):

The attached .tar.gz file should be expanded in directory "trunk" of the OpenWRT source tree. It will create subdirectory "package/telldus-core". Under that one there will be two files, a Makefile which is based on Micke's makefile for 2.0.4 and a patch file, which contains modifications to seven files in the telldus-core 2.1.1 sources. The source package itself will be downloaded directly from download.telldus.com when the package is built.

To build the package some preparations are needed: Run "make menuconfig" and

- enable "Compile with full language support" (full details can be found from http://www.mail-archive.com/discussion@ ... 01044.html) This is needed because telldus-core now needs libiconv, there are two alternatives for that, and the real libiconv is not enabled for OpenWRT by default. Additionally, when it is enabled, the files are not present in the standard locations.

- also enable building of "argp-standalone".

Other dependencies should be listed in the Makefile, so those should be enabled and built automatically.

Next, it should be possible to build telldus-core by executing "make package/telldus-core/compile V=99" (unless I forgot something; I haven't had time to double-check these instructions - sorry!)

The results can be found from a subdirectory under "bin" - for example, because I'm building for the ar71xx architecture, my binary package was created to bin/ar71xx/packages/telldus-core_2.1.1-1_ar71xx.ipk


Notes about installing and running telldus-core on OpenWRT:

Copy the binary pacakge to the router by e.g. scp, and then install it with opkg. If it complains about missing packages (libftdi, confuse, etc), those can be installed from the official repositories.

Once the package and all dependencies has been installed, there were some additional steps I had to make before telldusd could be started:

a) I had to add a "plugdev" group by editing /etc/groups

b) Even if udev was installed, udevd was not started automatically. I had some trouble when I tried to run it as a daemon, but starting it with "udevd --debug" (which keeps it in foregroud) works. At least for me.

c) I copied /etc/tellstick.conf from my desktop Linux host.

[N.B. I had already installed everything which is needed to get the USB port working - it isn't enabled by default. Instructions can be found from the OpenWRT wiki]

Next, I started "telldusd --nodaemon", plugged in my Tellstick Duo, it was detected and started to work. Except that telldusd failed to write to /var/state/telldus-core.conf, because the process had insufficient access rights. That can fixed for example by "chmod 775 /var/state; chgrp plugdev /var/state".

What is still missing is a proper startup script for OpenWRT. I'll have to write one next week, when I'm going to (trying to) make a permanent installation of this..


Comments about the changes:

First, two fixes were needed:

1) service/Log.h needs to include stdarg.h. For the usual Linux distributions (which use glibc), it is probably included as a side-effect of something else. However, OpenWRT seems to use uClibc.

2) tdadmin/udev.sh doesn't have to be a bash script; it works with /bin/sh, too. Trying to use bash just means that the script fails on OpenWRT, which doesn't have /bin/bash

The rest of the changes are more or less quick-and-dirty OpenWRT-specific hacks:

3) The most tricky part was modifying the cmakefiles to find and use the full version of libiconv. There are changes related to that in three files:
common/CMakeLists.txt, tdadmin/CMakeLists.txt and tdtool/CMakeLists.txt.
(I've written and used the ordinary Makefiles since 1980s, but this was the first time when I did something with cmake. The results are not pretty, but appear to work. It would be great it someone who knows how cmakefiles should be written for OpenWRT could fix these changes..)

4) common/Strings.cpp needs two small changes because one function in libiconv is not fully compatible.

5) service/CMakeLists.txt tries to install a file to /var/state, but for some reason the OpenWRT build system can't do that. I just commented that out. This is probably the reason why permissions of /var/state need to be set manually. There must be a way how this could be resolved correctly, but I'm not an OpenWRT packaging expert and didn't have time to resolve it properly.

Thank you for this.

I have pushed two of your changes upstream for the next release.
http://developer.telldus.com/changeset/ ... 4be7a32369
http://developer.telldus.com/changeset/ ... b58c5133f4

The patches for iconv needs more work since they currently break the build for other platforms. Iconv is implemented in libc and not available as a separate library. Some way to detect if uClibc is used and only the link it then is necessary.

Also, the patch in common/Strings.cpp breaks the build. The patch should do something similar to the ifdef used on FreeBSD a couple of lines above the patch.

Regarding udev. Is udev used in OpenWRT? A while ago, when I was invesigating this, a system called "hotplug" was more common on embedded system. If this still is the case the udev-script might be rewritten to use that system instead?

micke.prag wrote: The patches for iconv needs more work since they currently break the build for other platforms. Iconv is implemented in libc and not available as a separate library. Some way to detect if uClibc is used and only the link it then is necessary.

No, iconv is included in glibc, but for OpenWRT it is in a separate library. Which is big, and they have an alternative also, a fake library which only has stubs.

I think that the best solution would be to leave libiconv out completely on OpenWRT (to use conditional compilation for that). It wasn't needed for 2.0.4, was it? Is it absolutely necessary now?

Also, the patch in common/Strings.cpp breaks the build. The patch should do something similar to the ifdef used on FreeBSD a couple of lines above the patch.

Exactly. The problem is related to Cmake; I didn't find out yet how to set the platform information with that, and how to relay that information to the source code. So no #ifdefs anywhere, just rude patches to get the thing compiled and running.

Regarding udev. Is udev used in OpenWRT?

udev is available as a separate package. It isn't included by default. I forgot to list that as a dependency.

A while ago, when I was invesigating this, a system called "hotplug" was more common on embedded system. If this still is the case the udev-script might be rewritten to use that system instead?

I think OpenWRT is also using hotpug, and it makes sense to apply that in the future. But I wanted to start with minimal set of changes, to get 2.1.1 up in the original form.

What is a really big problem currently is that udevd seems to detect the Tellstick, but the information is only occasionally relayed to telldusd. I can see from the debug log that udevd starts the helper script each time, but "telldusd --nodaemon" doesn't seem to detect the Duo every time.

This might be related, it happens far too often:

I have two boxes running OpenWRT, and I'm having these communication problems only on one. Which has an USB hub, and the Duo is connected to the hub. If I connect the Duo directly to the other box there are no communication problems (or at least I haven't seen those messages ever).

Also, if udevd is running and the device is connected before telldusd is started, it finds the Duo reliably only on the system without the hub. On the system with the hub the device is detected only occasionally.

I don't know it the hub is causing these problems, but it can't be eliminated because other usb devices are also needed (and the buffalo has only one USB port)

Debug output from udevd looks very similar on both devices. There are just some minor differences related to USB addresses.

Unfortunately telldusd doesn't seem to be too friendly. I.e. it is completely silent if the device is not detected... Are there any additional debug flags available for telldusd?

Lauri wrote:No, iconv is included in glibc, but for OpenWRT it is in a separate library.

Yes, I know. That was what I meant.

Lauri wrote:I think that the best solution would be to leave libiconv out completely on OpenWRT (to use conditional compilation for that). It wasn't needed for 2.0.4, was it? Is it absolutely necessary now?

It is hard to compare 2.0 with 2.1 since 2.1 is a complete rewrite from scratch. In 2.0 the encoding relied on the current on the system. This meant it was different on every system and a pain to write third-party applications. That is why we now use utf-8 for all strings. This is why we need iconv.
If you can find another way to convert between wchar_t * and char * not using iconv, please let me know.

Lauri wrote:I don't know it the hub is causing these problems, but it can't be eliminated because other usb devices are also needed (and the buffalo has only one USB port)

Maybe you can try without the hub briefly? So we know what error to pursue?

micke.prag wrote:

Lauri wrote:I don't know it the hub is causing these problems, but it can't be eliminated because other usb devices are also needed (and the buffalo has only one USB port)

Maybe you can try without the hub briefly? So we know what error to pursue?

I did that. Seems to work fine without the hub. No communication problems in ca. 30 minutes. When it is connected to the hub, there lots of reconnects in that kind of timeframe.

The hub has a seven ports and an external power supply and is made by Belkin, so at least it isn't one of the cheapest ones, but it is of course impossible to say what that means to quality. In any case I haven't had any problems with this hub and the other connected devices.

Unless we can solve this today, it is starting to look like I'll have to leave the other OpenWRT box here to control the Tellstick, and connect the two boxes by ethernet cable [a brief description of the application: I bought the tellstick duo to be able to read temperatures and control heating in a small loghouse, which is quite far from home. Heating is off by default during winter time. One of the other USB devices that must be connected is the 3G USB modem stick...]

Anyway, I have used the other OpenWRT box for testing and development purposes at home, and leaving it to the loghouse would mean that I'm not going to make any bigger changes before summer, unless I buy a third router (if something goes wrong with the SW installation, who wants to drive hundreds of kilometers just to reset a small router )

Lauri wrote: Unless we can solve this today, it is starting to look like I'll have to leave the other OpenWRT box here to control the Tellstick, and connect the two boxes by ethernet cable [a brief description of the application: I bought the tellstick duo to be able to read temperatures and control heating in a small loghouse, which is quite far from home. Heating is off by default during winter time. One of the other USB devices that must be connected is the 3G USB modem stick...]

Anyway, I have used the other OpenWRT box for testing and development purposes at home, and leaving it to the loghouse would mean that I'm not going to make any bigger changes before summer, unless I buy a third router (if something goes wrong with the SW installation, who wants to drive hundreds of kilometers just to reset a small router )

I suggest that you check how much power your USB-hub can provide. I don't think you will find a 3,5A power-adapter there, so possibly the problem is that your hub can not provide enough power. Try the hub without 3G-modem for instance just to know if that improves performance.

There are tree more patches in the attachment (these are generic changes, not specific to OpenWRT):

The first one is actually quite important, it fixes some bashisms in udev.sh. It is important, because my previous change to udev.sh (Micke already integrated it) now runs the script with /bin/sh, and so the script should only use posix-compatible features. Otherwise udev.sh won't work when e.g. "dash" is used as /bin/sh (like debian does). There were no problems when /bin/sh was "bash" or the busybox shell. I'm really sorry that I didn't notice that earlier.

The second patch is a minor fix, and the third patch adds an alternative device/sensor listing format to tdtool. It is a bit easier format to process with simple scripts, and makes life a lot easier for me. Especially because it also prints age of the data in seconds: Simple embedded systems, like the routers running OpenWRT, typically don't have RTC chips. And updating time from NTP servers seems to be somewhat unreliable (that is probably an OpenWRT bug), so often only relative times (ages) are meaningful.

---

About the USB hub issue: I'll check the power supply on my next visit, it is a good idea. Although I think there should be enough available even if the power supply couldn't provide 3.5 amps. Currently there is still two free ports and the 3G modem and the Tellstick are the only connected devices which might need more power. I'll try to test with other types of hubs, too.

Thank you for those patches. They are now pushed to master.

It would also be interesting if you can run your TellStick Duo with your hub but without the 3g-modem.

please Lauri or micke.prag can you make a package telldus-core for OpenWRT(Asus WL-500g Premium V2) ? it is much complicated for me. very thanks

i have standard tellstick, no need receive support...

please help i cannot make package its very very complicated.

babina@OpenWRT:~/openwrt/trunk$ make /package/telldus-core/compile V=99 make[1]: Entering directory `/home/babina/openwrt/trunk'
make[1]: *** No rule to make target `/package/telldus-core/compile'. Stop.
make[1]: Leaving directory `/home/babina/openwrt/trunk'
make: *** [/package/telldus-core/compile] Error 2

uzivatel wrote: $ make /package/telldus-core/compile

There is an extra leading slash before "package", try if make package/telldus-core/compile works for you.

hello everybody,

hardware: Asus WL-500g Premium V2, Tellstick (not duo)
firmware: OpenWRT Backfire 10.03.1-rc4

compiled packages on trunk openwrt buildroot, install all dependencies etc.

dmesg:

usb 2-1.2: new full speed USB device using ohci_hcd and address 6
usb 2-1.2: configuration #1 chosen from 1 choice
ftdi_sio 2-1.2:1.0: FTDI USB Serial Device converter detected
usb 2-1.2: Detected FT232RL
usb 2-1.2: Number of endpoints 2
usb 2-1.2: Endpoint 1 MaxPacketSize 64
usb 2-1.2: Endpoint 2 MaxPacketSize 64
usb 2-1.2: Setting MaxPacketSize 64
usb 2-1.2: FTDI USB Serial Device converter now attached to ttyUSB0

tdadmin work
tdtool work

telldusd not work with result Segmentation fault

Any idea what is wrong? tkanks

uzivatel wrote:usb 2-1.2: FTDI USB Serial Device converter now attached to ttyUSB0

It looks like you have ftdi_sio loaded in the kernel. Unload that.

uzivatel wrote:telldusd not work with result Segmentation fault

Cannot say why. It it to generic and a backtrace whould be necessary. Parhaps some permissions to /etc/tellstick.conf and/or /var/state/telldus-core.conf?