TX22 devices not decoded correctly

[tnick61]

Hi
I have installed the tfrec docker image as described.
All IT Dossmann devices are decoded correctly. However I am experiencing a problem with my TX22 device.
The "sensor_id" seems not to be created correctly for all data packages and no data is contained in the "humidity" data fields.
In the docker logs, humidity is missing completely.
I have tfrec also installed on a Raspberry Pi installation, where it is working correctly.
I am using the same start command in both installations. In both installations i am using the tfrec-mqtt.sh scripts to push messages to my mqtt server.
What code base of tfrec has been used?

[git-developer]

The image tag contains the tfrec commit hash. latest is also tagged as 2022-08-17.bf0803b which is the latest tfrec commit.

[git-developer]

Could you please check if your problem applies to JSON format, to raw format or to both formats (see env variable FORMAT_RAW)?

[tnick61]

Hi Christian
The raw format seems to have the same problem as the JSON format.
The TX22 should send 5 different message formats, resulting identified in mqtt topic with different sensor_ids. However it seems only 4 are being created. Maybe this gives a hint where the problem may come from.
In the original description of tfrec the sensor_ids for TX22 should start with 3000.... I am receiving sensor_ids of which start with 330000..
Regards Thomas

[git-developer]

OK. Please stop the docker container and run tfrec manually with your args, e.g.

docker run --device /dev/bus/usb --rm ckware/tfrec-mqtt /usr/local/bin/tfrec -T 8 -D

This should print out all received messages on the screen. Please report back if the problem still occurs.

[tnick61]

With the debug option enabled, the different TX22 messages show up in the log, but all with the same ID ID 30000080. So something seems to go wrong with converting the TX22 messages.

[git-developer]

When the output of tfrec is not as expected, I can't help out here, sorry. This project just processes the output of tfrec. Please consider reporting your issue in the tfrec project.

[git-developer]

I have tfrec also installed on a Raspberry Pi installation, where it is working correctly.

I don't understand that. tfrec should behave the same, no matter if run on the host or within a container. I don't know your setup, but you can try to gain insights by running tfrec-mqtt on the Pi using the command above. Maybe the position of the antenna is different?

[git-developer]

In the original description of tfrec the sensor_ids for TX22 should start with 3000.... I am receiving sensor_ids of which start with 330000..

vs.

the different TX22 messages show up in the log, but all with the same ID ID 30000080

This reads contradictory. Anyway, the id generation is part of tfrec (as noted above), so there's nothing I can do about this in tfrec-mqtt.

[tnick61]

The reception conditions of both installations is identical and I have no BAD messages in the log. The TFA1 sensors are decoded flawlessly. In the meantime I have managed to write the raw messages of both installations to a log file, in order to compare them. In Docker installation, the message with id xxx1 is missing. The reading for humidity, which should show up in a dedicated message, shows sometimes up in the same message with id xxxx0 together with the temperature value. So it must be a flaw in the tfrec code. I have Docker running on Proxmox. Could the problem potentially be caused by the usb device forwarding into the container causing that some bits will be missed? Unfortunately I am not a SW pro and the tfrec code is difficult for me to understand ;-).

[git-developer]

I have Docker running on Proxmox.

Sounds like 2 layers of virtualization. The simpler the setup is, the easier you can find the root cause. I have no experience with Proxmox. If you have the chance to run the container directly on the host, you could find out if the problem is related to the combination of Proxmox and Docker.

To find out if something in the image is the culprit, I created another image that might help debugging. It is based on Debian Linux instead of Alpine. You can run it as follows:

docker run --device /dev/bus/usb --rm ckware/tfrec-mqtt:bookworm.2022-08-17.bf0803b /usr/local/bin/tfrec

You can now compare the output of the default (Alpine) image to this (Debian) image.

Where does your tfrec binary come from? What is your os & arch?

[tnick61]

Sorry for my late replay.
I am facing a strange issue. I have tried to re-install an new docker container with the recommended image. Result: I am getting lots of "Unable to connect (Lookup error.)" errors in the containers log. Was so far not able to identify the root cause. Happens also with the "normal" image if re-installed or if am using the -f option to correct frequence offset. Must be some kind of timing issue in my installation.
My approach to install tfrec alone in lxc container directyl on Proxmox failed so far since I could not get the rtl-sdr path through working (right issue). See the rtl-sdr stick with lsusb but stick is not coorectly installed under /dev. Followed my descriptions in the forums ;-).

[git-developer]

The message
Unable to connect (Lookup error.)
probably means that the container cannot resolve the ip address of the broker. I don't think that this is a timing issue.

1. Check the hostname broker in your MQTT_OPTIONS variable. You may use an IP address instead of the hostname, too.
2. You can manually try a lookup by running docker exec tfrec-mqtt nslookup HOSTNAME_OF_YOUR_BROKER
3. Where does your broker run?

[git-developer]

Please report back if your request still requires attention.

[tnick61]

I guess I've found the issue after some investigation.
There seems to be a failure in the original tfa2.cpp, which causes the TX22 humidity option (id x1) not correctly coded. I had corrected this by myself a few years back when I installed it on my Pi , but never reported it because I thought it a failure on my side.
I have attached "my version" of the tfa2.cpp file. With diff you'll find the my changes.
Maybe you're able to incldude it in your docker file ;-).
With this change you should see following debut output with tfrec -T 8:

33000081 +0.0 xx 0 0 ......

tfa2.cpp.txt