Additional sensors for ESH/OH2 OneWire binding

The sensor is a mv-tv. It was working fine with your original release.
The owfs-data:

26.59F7D6010000



uncached version

pages-data:

26.59F7D6010000/pages



uncached version
up directory
B1-R1-A B1-R1-A
CA
EE
HIH3600 HIH3600
HIH4000 HIH4000
HTM1735 HTM1735
IAD
MultiSensor MultiSensor
S3-R1-A S3-R1-A
VAD 0.41
VDD 4.63
address 2659F7D60100008D
alias
crc8 8D
date
disconnect disconnect
endcharge endcharge
family 26
humidity -13.0168
id 59F7D6010000
locator FFFFFFFFFFFFFFFF
offset
pages pages
r_address 8D000001D6F75926
r_id 000001D6F759
r_locator FFFFFFFFFFFFFFFF
temperature 5.03125
type DS2438
udate
vis -0.249958
up directory
page.ALL 070005D90000FC00D92C1D00000800FC000000003D8617000000000000000000 000000000000000000000000000000000000000000000000000000000200FFFF
page.0 070005D90000FC00
page.1 D92C1D00000800FC
page.2 000000003D861700
page.3 0000000000000000
page.4 0000000000000000
page.5 0000000000000000
page.6 0000000000000000
page.7 000000000200FFFF

Thanks. I use (and I think that has not changed) the first byte in page 3 to distinguish the several multisensor-types. Your sensor has 00 which is not a known code. Therefore the discovery-service cannot decide which sensor that is. Who is the vendor of that sensor? It is still possible to add that sensor manually (as MS-TV or whatever is the correct one).

Regarding the DS2423: I found a typo. The updated JAR is in the first pos. Please check that. If the excepetion still occurs, please do

log:set DEBUG org.eclipse.smarthome.binding.onewire.internal.handler.CounterSensorThingHandler

on the console. I need the exception message. Thank you.

Best Regards,

Thanks @J-N-K. The DS2423 works perfect now, unfortunately none of my other sensors work now.

2018-10-10 13:34:28.723 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NumberFormatException: null
        at java.math.BigDecimal.<init>(BigDecimal.java:494) ~[?:?]
        at java.math.BigDecimal.<init>(BigDecimal.java:383) ~[?:?]
        at java.math.BigDecimal.<init>(BigDecimal.java:806) ~[?:?]
        at org.eclipse.smarthome.core.library.types.DecimalType.<init>(DecimalType.java:57) ~[?:?]
        at org.eclipse.smarthome.core.library.types.DecimalType.valueOf(DecimalType.java:71) ~[?:?]
        at org.eclipse.smarthome.binding.onewire.internal.owserver.OwserverConnection.lambda$0(OwserverConnection.java:206) ~[?:?]
        at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) ~[?:?]
        at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) ~[?:?]
        at org.eclipse.smarthome.binding.onewire.internal.owserver.OwserverConnection.readDecimalTypeArray(OwserverConnection.java:206) ~[?:?]
        at org.eclipse.smarthome.binding.onewire.internal.handler.OwserverBridgeHandler.readDecimalTypeArray(OwserverBridgeHandler.java:132) ~[?:?]
        at org.eclipse.smarthome.binding.onewire.internal.device.DS2423.refresh(DS2423.java:54) ~[?:?]
        at org.eclipse.smarthome.binding.onewire.internal.handler.OwBaseThingHandler.refresh(OwBaseThingHandler.java:158) ~[?:?]
        at org.eclipse.smarthome.binding.onewire.internal.handler.OwBaseBridgeHandler.refresh(OwBaseBridgeHandler.java:71) ~[?:?]
        at org.eclipse.smarthome.binding.onewire.internal.handler.OwBaseBridgeHandler.lambda$0(OwBaseBridgeHandler.java:49) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

Regarding the DS2438, its a maxim DS2438 chip on a home made circuit board.
When I add it manually I get the same error of cannot be mapped to thing type.

Same problem here - the binding is throwing exception on start.

However I don’t think my counter works - it does not have correct value. It is the old one from persistence db.

DS2423: Ok. So something is read but cannot be parsed. I have added debugging for that. Updated JAR above. Your other sensors are nor working because of the excpetion above.

DS2438: I cannot see from the source where this message should come from. If you add the sensor manually the message appears in your log? Or does it appear when you do a discovery scan after you added it manually? If the latter, that is expected. The discovery service finds the sensor but cannot map it. One workaround would be to go to /pages, enter F400000000000000 in page.3 and press “Change”. This will make the binding auto-detect the correct sensor-type.

Edit: a screenshotof the DS2423 would be great. Maybe I have some misinterpretation of the owfs-documentation here.

Here is the log:

2018-10-10 21:09:34.048 [INFO ] [internal.owserver.OwserverConnection] - requestPacket messageType READ, size 54, controlFlags 0x00000100, payload '/1D.96D20F000000/counters.ALL'
2018-10-10 21:09:34.206 [INFO ] [internal.owserver.OwserverConnection] - returnPacket return code 25, size 49, controlFlags 0x00000104, payload '        3834,           0'
2018-10-10 21:09:34.208 [INFO ] [internal.owserver.OwserverConnection] - read '        3834,           0', split to [3834,            0]
2018-10-10 21:09:34.211 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NumberFormatException: null

Thanks. That explains it. The additional spaces after the , made the number conversion fail. I thought it was like 3834,0, not 3834, 0. Fixed. Next try in first post.

Yep, much better :slight_smile:
Thanks for quick fix.

Can you please make another version with logging level of those messages changed to debug?
Now they are polluting my log file… :wink:

Done.

1 Like

OK, spent several hours this morning fighting with it and have at last got rid of the multiple owserver bindings. I think that what happened was there were two instances of the one-wire binding, one from the services configuration file and one from the karafe console. The other thing that was wrong was that I was running the stable version of openhab2 which didn’t have the Openhab2 version of the onewire binding available to it. Hence I never saw that binding available in PaperUI which was confusing me. I’ve switched to “testing” and I’m now getting many more 2.4 bindings, including onewire.

I’m now trying to get my head round configuring onewire things and items. I have the bridge config set up but don’t as yet see any attempt to connect to owserver. I’ll keep fiddling.

@J-N-K, I’ve been using your latest jar for the last three days and everything is running great! Doing the workaround on the /pages worked, and the DS2423 is working fine.
Thanks again for your work on this!

Are you using discovery in PaperUI to configure the bridge and things? If your owserver is on another computer in your network, make sure you have access to it from your openHAB server.

No, I entered the bridge information manually into onewire.cfg in /etc/openhab2/services. I’m just about to remove this and try doing it entirely from PaperUI. I’ve had onewire working perfectly on openhab1 for some time on the same machine so I’m pretty sure this is working.

The onewire.cfg in /services is for the old openHAB1 onewire binding. For the new openhab2 binding you have to configure it in PaperUI - or if you want to do it manually, you have to add it as a thing in /etc/openhab2/things.
For more info, see: https://www.openhab.org/addons/bindings/onewire/#thing-configuration

Yes, I had temporary brain fade. I’ve tried both manually and via PaperUI. In neither case do I get an autodiscovery of Onewire devices.

Ah ha! Leaving it quietly for a bit and it has found a whole bunch of 1-wire devices. Not the EDS devices though, which I assume is due to the fact that I’m using the standard 2.4 binding.

@J-N-K seems I spoke too soon. The DS2423 doesn’t seem to update consistently… It works fine after a restart then stops updating after a short while. I turned on DEBUG for the binding but no debug messages are showing up in the log?

What about the other sensors? Are they still updating when this happens?