My forum

Traced the execution path, and indeed it seems like the string: class:sensor;protocol:fineoffset;model:temperaturehumidity;temp:-20.4;humidity:0xFF;id:0xFF; comes directly from the firmware, so apparently I'm out of luck (at least with the stock firmware in the device) with both weather sensors, des...

Any news on opening the duo firmware code? Got a couple of weather stations from Clas Ohlson, one of which gives a promising blink on the Duo, but temperature & humidity are bogus (0xff). Would like to find out if they can be gotten to work, some more details at http://www.telldus.com/forum/view...

One interesting-looking approach to add 433.92 Mhz comms (among other things) to the Raspberry Pi is a piggyback board with a RFM22B radio, infrared receiver, a wMBUS stack, RTC clock with battery, breadboard area etc. http://www.raspberrypi.org/phpBB3/viewtopic.php?f=45&t=13264 http://www.raspb...

Apparently the 20.4 temp at the start value probably was a correct observation after all - looks like there are occasional bit errors in the readings, which sometimes result in 20.4. But mostly it's -20.4. SENSORS: PROTOCOL MODEL ID TEMP HUMIDITY LAST UPDATED fineoffset temperaturehumidity 255 -20.4...

My guess is the extra fineoffset readings are a bit differently misread readings from your sensor (or radio noise), I've seen those too. Don't know about the Oregon humidity, maybe the sensor's protocol is not fully supported.

Hi, Update to this: Good news is that it appears the source is now available, see https://github.com/telldus/tellstick-duo Bad news is that according to the prerequisites specified, a proprietary C compiler / dev platform is required to compile the code. The price for that appears to be $1195 single...

Looked at the code, it doesn't seem too complicated. So, hopefully a port to a different compiler wouldn't be too complex, assuming the different compiler can create working code. Also, complexity doesn't seem too much to modify even in assembly.

Are you sure it works with the free (Lite) version? Or could it be that the downloaded compiler binary works in pro mode for 45 days evaluation period as a pro version?

Anyway, I've now got the compiler downloaded, perhaps I'll test.

I compiled with the lite mode (compiler offers the choice of demo mode or lite mode or license key mode at install time), and seems to work, with lots of message suggesting to use the PRO mode: Memory Summary: Program space used 2AF3h ( 10995) of 8000h bytes ( 33.6%) Data space used 5BAh ( 1466) of ...

Maybe the size difference has to do with different versions - the net site has a .hex file for firmware v4, but the published source is for v5 (for non-custom flashing v5 firmware is bundled in the flasher). The hex file I built is 31620 bytes. Seems I perhaps was a bit over-confident about (un)bric...

There's some ideas for protocol debugging (with a modified firmware) / adding new protocol support in the developer area at ticket http://developer.telldus.com/ticket/90

Thanks for the answers. I added some comments in the ticket system, at http://developer.telldus.com/ticket/90

Hmm - looking at the time stamp at the Oregon reading, I wonder if that could be bad reception or a badly-functioning sensor. There's a Mandolyn sensor reading at time 8.37, but the Oregon sensor reading is more than five hours older. I gather the readings are supposed to be updated whenever the sen...

Well, there is a firmware version with local access published as source code for the Net, but apparently it isn't considered as mature/stable as the normal firmware. I haven't tried this, don't even have a Net device - one of the main reasons for me in choosing the Duo instead was that the Net was r...

I set up a simple system to graph the 433,92 radio traffic - wire from a thermometer RFDAT contact to computer audio input and then run audacity on the computer. Bit density in the car key signal is higher than with the sensors & controls I have. Looks like visualizing the traffic this way will ...