Great job with the new OneWire binding
However at the moment, it is (at least for my application ) missing a key feature compared to the old binding, support of extended deviceIDs.
My setup is utilising DS2409, which is a MicroLan coupler that enables larger - and/or more reliant - networks by separating these in separate smaller networks. - Link
This means that a temperature sensor, eg. DS18B20, attached to the mail branch of a DS2409 is addressed as such with the old binding:
Would it be possible to “relax” the deviceID validations in the new binding to support this?
As I see it - without having looked into the code in the binding - it should not be necessary to add support for a new thing (DS2409) - I should be possible the ignore DS2409 but accept that devices can have a prefix and let the 1-wire network handle the addressing?
Please ad a GitHub issue for that. I’ll have a look but there are other things in the queue and I’ll forget that. I’m not too fond of allowing it in this way because this will leave some things out in the discovery. Please attach some pictures of the DS2409 in the issue, so I can see what is available (I don’t own these devices). And link this post. Thanks.
I have created a github issue - please forgive me, if it is not done correctly, as this a first for me -
It was easier than expected (I think). Please try this. I’m quite sure that manual configuration works, please check the discovery service. Thanks.
It works perfectly after discovery:
And a thing looks like this:
Thank you very much!
I will start to move everything to the new binding now.
Ok, this should be changed, the name should only contain the sensor ID, not the full path. Thanks.
one more thing.
When running discovery, the log entry for an empty branch is:
[INFO ] [internal.discovery.OwDiscoveryService] - could not get directory '/1F.C8C201000000/aux/' for onewire:owserver:mybridge
Perhaps a better description like “Empty branch (could not get directory) …”