Temp sensor returning bogus values!

Every week or so a temp sensor that sits on a wall of my not so hot house , comes up  with  a readout that should not happen.  In openhab it screws up autoscale graphs. I could add filtering rule but that should not happen in the first place.

mysql> select * from Item4 where Value >30

    -> ;

+---------------------+-------+

| Time                | Value |

+---------------------+-------+

| 2015-10-12 21:47:03 | 80.93 |

| 2015-10-21 01:23:41 | 48.93 |

+---------------------+-------+

2 rows in set (0.08 sec)

Have you tried to use the slow i2c mode with the set_i2c_mode funktion that the Temperature Bricklet API has?

Hi xsherlock,

this setting is not yet available for the openHAB binding. I will add it and give notice as soon as it is available.

Regards,

Theo

I've made the i2C setting available to the OH tinkerforge binding. You can download an updated binding from here (it will also run on older OH versions):

https://bintray.com/artifact/download/theoweiss/generic/org.openhab.binding.tinkerforge-1.8.0-SNAPSHOT.jar

Sample configuration is available here:

https://github.com/theoweiss/openhab-tinkerforge-configuration-examples/blob/master/temperature/openhab.cfg

You have to set "tinkerforge:xxxx.slowI2C=True"

I'm looking forward to get your feedback.

Regards,

Theo

ok added that to the config, now we need just to wait a bit.

I did not have any entries in the openhab.cfg regarding the specific briclets.

I addedd

tinkerforge:hosts=172.16.2.156

tinkerforge:temperature.uid=qnM

tinkerforge:temperature.type=bricklet_temperature

tinkerforge:temperature.slowI2C=True

Can I still refer to this bricklet by the uid in the items.

Number GF_Living_Temperature "Temperature [%.1f C]" <temperature> (GF_Living) {tinkerforge="uid=qnM"}

Can I still refer to this bricklet by the uid in the items.

Yes, there is no need to use the symbolic name.

Any news?

Looks good no bogus numbers since nov-2 when I implemented the change

mysql> select * from Item4 where Value >30

    -> ;

+---------------------+-------+

| Time                | Value |

+---------------------+-------+

| 2015-10-24 09:47:46 | 32.93 |

+---------------------+-------+

1 row in set (0.16 sec)

mysql> select * from Item4 where Value <10

    -> ;

+---------------------+---------+

| Time                | Value  |

+---------------------+---------+

| 2015-10-13 23:38:41 |  -79.06 |

| 2015-10-14 14:14:05 | -111.06 |

| 2015-10-30 15:51:15 |  -31.06 |

+---------------------+---------+

3 rows in set (0.12 sec)

Thanks for your feedback!

Theo,

Is the Tinkerforge addon distributed with Openhab 1.8.0  the same you gave me for download?

I did upgrade to 1.8, by uninstaling and doing a proper apt-get 1.8, then  overwritten the configs with my tried and working 1.7 setup and I get the negative -100 values again.  Twice in the last 3 days. And now it is even worse as the redbrick I have sensor attached stops responding at all. hanging up the readout until I reboot.

Did you add this line to your configs again?

tinkerforge:temperature.slowI2C=True

It is still there, I copied all the 1.7 configs and just checked it again.

Hm, can you check the startup logs.

Looks clean to me.

2016-01-18 23:57:27.060 [ERROR] [.t.internal.TinkerforgeBinding] - COMMAND no tinkerforge device found for command for item uid: kDz subId: relay1
2016-01-18 23:57:27.915 [ERROR] [.t.internal.TinkerforgeBinding] - COMMAND no tinkerforge device found for command for item uid: kDz subId: relay2
2016-01-18 23:57:28.965 [ERROR] [.t.internal.TinkerforgeBinding] - COMMAND no tinkerforge device found for command for item uid: kDz subId: relay1
2016-01-18 23:57:29.862 [ERROR] [.t.internal.TinkerforgeBinding] - COMMAND no tinkerforge device found for command for item uid: kDz subId: relay2
2016-01-19 00:00:10.737 [iNFO ] [penhab.io.rest.RESTApplication] - Stopped REST API
2016-01-19 00:00:29.513 [iNFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.8.0).
2016-01-19 00:00:34.655 [iNFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started
2016-01-19 00:00:35.146 [iNFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Discovery initialization completed.
2016-01-19 00:00:35.171 [iNFO ] [.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2016-01-19 00:00:35.173 [iNFO ] [o.i.t.m.i.MqttBrokerConnection] - Starting MQTT broker connection 'mymosquitto'
2016-01-19 00:00:43.455 [iNFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.sitemap'
2016-01-19 00:00:44.323 [iNFO ] [c.internal.ModelRepositoryImpl] - Loading model 'mysql.persist'
2016-01-19 00:00:44.509 [iNFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.items'
2016-01-19 00:00:45.242 [iNFO ] [penhab.io.rest.RESTApplication] - Started REST API at /rest
2016-01-19 00:00:50.530 [iNFO ] [.o.u.w.i.servlet.WebAppServlet] - Started Classic UI at /classicui/openhab.app
2016-01-19 00:00:55.011 [iNFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.rules'
2016-01-19 00:00:56.368 [iNFO ] [.service.AbstractActiveService] - HTTP Refresh Service has been started
2016-01-19 00:00:56.971 [iNFO ] [.service.AbstractActiveService] - Tinkerforge Refresh Service has been started
2016-01-19 00:00:56.972 [iNFO ] [.service.AbstractActiveService] - NTP Refresh Service has been started
2016-01-19 00:01:35.830 [iNFO ] [c.internal.ModelRepositoryImpl] - Refreshing model 'default.items'
2016-01-19 00:04:36.069 [iNFO ] [c.internal.ModelRepositoryImpl] - Refreshing model 'default.sitemap'

I hooked up a PTC probe and unfortunately it also looks that it does return bogus temp values.

Can it take

tinkerforge:temperature.slowI2C=True config parameter?