[jeelink-lacrosse] Channel is not decoded

[Athan1]

Ther are LaCrosse sensors (like TFA 30.314), that provide two temperatures using two channels. org.openhab.binding.jeelink dose not take care about this information. Therfore sensors like TFA 30.314 are showing strange behavior.

The information about the channel is combined with the type. I think the second bit is the channel information.

Here two readings from my TFA 30.314: OK 9 59 130 4 56 125 OK 9 59 1 4 158 106 The correct representation of this is: tempreture2: 8.0 °C tempreture1: 18.2 °C (don't now about the humidity values, since the sensor is temperature only)

[vbier]

According to the source code of the lacrosse sketch, there is no channel in the message. The following comment is taken from the sketch:

  // Format
  //
  // OK 9 56 1   4   156 37     ID = 56  T: 18.0  H: 37  no NewBatt
  // OK 9 49 1   4   182 54     ID = 49  T: 20.6  H: 54  no NewBatt
  // OK 9 55 129 4 192 56       ID = 55  T: 21.6  H: 56  WITH NewBatt 
  // OK 9 ID XXX XXX XXX XXX
  // |  | |  |   |   |   |
  // |  | |  |   |   |   --- Humidity incl. WeakBatteryFlag
  // |  | |  |   |   |------ Temp * 10 + 1000 LSB
  // |  | |  |   |---------- Temp * 10 + 1000 MSB
  // |  | |  |-------------- Sensor type (1 or 2) +128 if NewBatteryFlag
  // |  | |----------------- Sensor ID
  // |  |------------------- fix "9"
  // |---------------------- fix "OK"

Is what you mean the sensor type? We had no clue what this is for when reviewing the pull request, so Kai decided to have it removed, see https://github.com/openhab/openhab2-addons/pull/1541#discussion_r118943000.

Do you have any additional information on the sensor type field?

[Athan1]

Hi Volker, yes I think thats what's ment. The readings from the two devices with two temperture sensors I own are

OK 9 0 130 4 204 125
OK 9 59 130 4 42 125
OK 9 59 1 4 52 106
OK 9 0 1 4 202 106
OK 9 0 130 4 204 125
OK 9 59 130 4 42 125
and so on

The humidity is not of intrest since the device has no sensore for that. The device is alway sending one block ''OK 9 XX 1 ..." and a second block "OK 9 XX 130 ..." where XX is the adress of the device.

001: 0000 0001
130: 1000 0010

So it looks a lot like that the 'sensor type' is what I'm missing.

I also had a look at FHEM whichs handling my sensors fine. They are splitting the seven bits for the sensor type in two different values the lower four are called channel, next three are called type (the highest is new bettery as documented).

To me it looks like the type is indeed use to identify some devices when talking to a wether station. The channel is uses to report additional mesuerments. The name oft the reported value always has the channel as appendix.

[vbier]

If the sensor type only has values 1 and 2, that would mean I could add a second set of channels to the thing for the additional temperature / humidity. But how can i detect if the second "sensor" only has temperature, or also humidity?

Can you point me to the FHEM code where you saw how this is correctly handled?

[Athan1]

Both of my sensor allways reports 125 in the byte for humidity byte. Since values above 100% should not be possible that might be the point.

You can find the FHEM-Code at https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/36_LaCrosse.pm The decodeing ist done in lines 183 - 217.

[vbier]

Okay, the type is extracted in line 213, but it is only used again in the if expression in line 415. I am wondering how this can work in FHEM. Or do I miss something here?

[Athan1]

Line 213 three bit from the upper nibbel are extracted for the type. Line 214 the lower four bit are extracted as channel. The intresting information is for my sensors is the channel. Line 472 a value called "temperature$channel" is updated.

By the way: Maybe we want switch to german, since I suspect thats the native language for both of us.

[vbier]

As this might be read by other people, I would prefer to continue in english.

Okay, it looks like the first bit is for new battery flag, the next three bits are sensor type and the last 4 bits of byte 1 are channel info. The comment above the code does not really reflect what they are doing.

I could parse the channel info and add additional temperature and humidity channels for channels 2..4. The sensor thing would then have channels Temperature2 and Humidity2. I am not sure if this is possible or how this is done. I have to check how to dynamically add channels to things and will keep you updated.

[vbier]

Adding channels was easier than I thought. @Athan1, can you please test this version and hopefully confirm that it works? I have tested this with netcat and TCP Jeelink and it seems to be working: https://github.com/vbier/openhab2-addons/raw/addSensorChannel/addons/binding/org.openhab.binding.jeelink/org.openhab.binding.jeelink-2.3.0-SNAPSHOT.jar

[Athan1]

The second channel is nicely added as "jeelink:lacrosse:59:tempreture2" and "...:humidity2". But I've trouble maping the new channels to items. Using Paper UI nothing happens when clicking on the link button. Using the items-File the item is created, but I don't think the channel is maped correctly, because no mesurement is showing up. All other channels are still working fine.

The traces are looking fine to me:

2018-01-15 21:07:24.688 [TRACE] [.LaCrosseTemperatureReadingConverter] - Creating reading from: OK 9 46 1 4 138 53
2018-01-15 21:07:25.479 [DEBUG] [sse.LaCrosseTemperatureSensorHandler] - updating states for channel 2 of thing LaCrosse Sensor Meeries (59): temp=6.9 (6.894998), humidity=125
2018-01-15 21:07:25.596 [TRACE] [connection.AbstractJeeLinkConnection] - Read line from port /dev/ttyUSB0: OK 9 59 130 4 46 125
2018-01-15 21:07:25.600 [TRACE] [.LaCrosseTemperatureReadingConverter] - Creating reading from: OK 9  59 130 4 46 125

[vbier]

I have not tried to link via the paper ui. I created an items file for the two channels and after that they show up in paper ui (but the temperature 2 is missing the unit, will have to look into that). I can see updates in the event log for the items as well.

Your posted log looks good as well. Are you sure you defined the items correctly? Do you get any updates in the event log?

Edit: the problem with the missing units is fixed, channels look identical to the "normal" channels now in paper ui.

[Athan1]

I'll have a look at it, but it will take 2-3 days.

[Athan1]

I just had a look at the new version (2.3.0.201801161420). Looks good!

The observed problems probably have been my mistake. After I had removed the sensore form my configuration completly and added it again, every thing was fine.

Thanks a lot! I'm quite happy.

[Athan1]

I have it tested for a week by now. It still looks good. Thanks again.

[vbier]

@Athan1, can you please reopen? I still have to create the pull request to get the changes into the official code.

[Athan1]

Sorry.