DS18x20 only some out of all sensors published

[ThomDietrich]

Hello,
I've got a Sonoff Basic with two DS18b20 connected. It's well configured and values for both sensors are correct. The problem is, that at times only one of the two sensors is covered by the SENSOR topic message.

openHAB prints an error message each time that happens. openHAB will look for the defined JSONpath selector and print an error if it can't be found:

2017-11-18 13:11:43.252 [ERROR] [.mqtt.internal.MqttMessageSubscriber] - Error processing MQTT message.
org.openhab.core.transform.TransformationException: Invalid path '$.DS18x20.DS2.Temperature' in '{"Time":"2017-11-18T13:11:42", "DS18x20":{"DS1":{"Type":"DS18B20", "Address":"28D025FB05000020", "Temperature":3.0}}, "TempUnit":"C"}'
        at org.openhab.core.transform.TransformationHelper$TransformationServiceDelegate.transform(TransformationHelper.java:67) [179:org.openhab.core.compat1x:2.2.0.201711152010]
        at org.openhab.binding.mqtt.internal.MqttMessageSubscriber.processMessage(MqttMessageSubscriber.java:138) [211:org.openhab.binding.mqtt:1.11.0.201711160210]
        at org.openhab.io.transport.mqtt.internal.MqttBrokerConnection.messageArrived(MqttBrokerConnection.java:556) [219:org.openhab.io.transport.mqtt:1.11.0.201711160210]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.deliverMessage(CommsCallback.java:475) [219:org.openhab.io.transport.mqtt:1.11.0.201711160210]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.handleMessage(CommsCallback.java:379) [219:org.openhab.io.transport.mqtt:1.11.0.201711160210]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:183) [219:org.openhab.io.transport.mqtt:1.11.0.201711160210]
        at java.lang.Thread.run(Thread.java:748) [?:?]

I could live with the error and it doesn't cause any further issues. However I wonder if this is the desired way of operation. If there are two sensors, shouldn't both be published at all times?

Best!

[arendst]

If a sensor readout supplies wrong data according to crc I do not want to send the unreliable data so sometimes a sensor is not reported.

[ThomDietrich]

I see. A retry is not an option? Any other ideas how to resolve this?

[ionciubotaru]

send status 10 until you receive information from both sensors

[ThomDietrich]

that's not solving the issue. I'm asking for a controller side retry...

[arendst]

A correct reread of the sensor involves a re-convert taking up to almost a second for 12-bit conversion which in turn hold up the reporting cycle.

If all is well the next teleperiod this re-convert cycle is performed and the sensor should provide a valid readout.

[ThomDietrich]

Yes, understood. Still the issue remains: The json response does not contain data expected by openHAB and will hence yield the warning seen above. Because of possible causes for such a case I'd say that openHAB behaves right and this needs to be addressed on the Sonoff side. Do you see a possible solution or will we have to live with that warning? It's not ideal, on the other side I am probably one of only a few users with more than one sensor connected.

[arendst]

I see no other solution than that openHAB has to check what data is in the JSON message. If a sensor is not there openHAB should not try to use it. That's the advantage of JSON; you can dynamically provide information.

[ThomDietrich]

I see. I suppose you are right. The problem is, that openHAB offers MQTT topic subscription and jsonpath transformation as two separate functions. We would need to check which part needs to be improved to support partial json responses. Either the jsonpath or all transformation services or the MQTT binding or a combination of both.
@davidgraeff what's your opinion on the matter, related to eclipse-archived/smarthome#3876 ?

[davidelang]

what information is missing?

[arendst]

I rewrote xsns_05_ds18x20.ino to accomodate the DS1822 (obsolete but nice to have). Other changes that might influence your experience are:

• Sensor probing only done once at power on. This eliminates lost sensors due to dynamic probing
• Address display corrected as the original calculation was reversed and showed both CRC and device type too.
• Add debug information regarding amount of sensors found and CRC errors.

To be released in next (pre)release.

[davidgraeff]

@ThomDietrich The proposed new OpenHab/ESH MQTT Things and their channels can be configured with an optional transformation. If the requested transformation does not yield a valid result, the Thing channel is not updated. "partial json" as you call it works out of the box.

[ThomDietrich]

@davidgraeff amazing! ;) Thanks again for the said PR.
@arendst with that the issue is settled.

[jhlweb]

@arendst, Can the dynamic probing be made into an compile option? All above reasons are greet but dynamic probing is something i use. I also use OH2 and i made script that controls that part of the dynamic probing as a feature. ( I also alter the Tasmota firmware every time to add CLEINT_ID to the TELE and STAT json because OpenHab doesn't have the capability to parse the topic to a script and my sensor are all on the same topic see also #975)

[arendst]

@jhlweb Just stick to the legacy version then which still has dynamic probing (and loss).