The sensor is a mv-tv. It was working fine with your original release.
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.
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:
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
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:
Thanks. That explains it. The additional spaces after the
, made the number conversion fail. I thought it was like
3834, 0. Fixed. Next try in first post.
Yep, much better
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…
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?