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
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.
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.
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.
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
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?