Re: [Owfs-developers] Announcing a new Python library
On 05.09.2018 11:00, Jan Kandziora wrote: > Yes, exactly. But that's what a clever designed library can assist the > application programmer. By requiring him to think about the logical > abstraction of a whole device first, not just a Onewire slave. Well, I can't help with "requiring". But once the logical abstraction is established, the 1wire library needs to fit into the concrete code that maintains the abstraction in a way that won't require it [more than absolutely necessary] to pay attention to 1wire-specific issues like co-ordinating scanning /alert or writing to /simultaneous, and which won't break [more than unavoidably] when Things Happen to the bus. And that in turn requires more support from the 1wire library than the ability to call read, write, and getdir. That's the easy part. -- -- Matthias Urlichs signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Announcing a new Python library
Am 05.09.2018 um 10:08 schrieb Matthias Urlichs via Owfs-developers: > >> The DS2409 is already transparently supported by owlib. > Is it? > > Last time I checked, slaves behind a DS2409 or two do not show up > in "owdir /" or "owdir /bus.0" or "owdir /alarm", they do not > notice when I set /simultaneous/temperature, … > > So either I'm missing something, or your definition of > "transparent" differs from mine. :-/ > What you mean is *flattened*. Transparent means you don't have to care for the details of controlling the DS2409's switches on the way by hand if you want to access a certain device. Owlib does that for you. Also, it uses the special branch prefix command to access/enumerate only devices on a branch instead of the whole bus. This can speed up things a lot, e.g. if you have passive iButton locks marked with a single DS2409. I personally don't care if a library creates symbolic links in the main directory. That's one single run through the structure at the beginning. > > For one, support for (bus-specific) handling of /alarm or > /simultaneous. > Yes. > The idea is that different 1wire buses may have different > requirements (timing, polling, alarm handling, how often to trigger > temperature conversion, bus re-enumeration, …); it's the client > system's job to coordinate the device instances' requirements to do > the least-possible amount of work, and only on the bus(es) it cares > about. > Yes, exactly. But that's what a clever designed library can assist the application programmer. By requiring him to think about the logical abstraction of a whole device first, not just a Onewire slave. I understand that's not a simple thing to do for a library aiming at different targets on both sides, but putting in another abstraction layer which then fails to abstract things proved pointless to me. That's why I did this abstraction in my application program, which knows about the devices it controls. Kind regards Jan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Announcing a new Python library
On 05.09.2018 07:45, Jan Kandziora wrote: > So my advice from pratice is basing all the automatical mechanisms on > a logical abstraction of a whole peripheral, with the Onewire stuff > being only a part of a bigger picture. My main goal with this library is that the instance representing a slave device should be able to tell the system what it want, and be able to rely on the library to do it, instead of being forced to do all the work by itself. The "big picture" abstraction is the job of projects like HomeAssistant (since we're talking Python …), which currently has no 1wire support to speak of – which is one reason why I'm doing this. > The DS2409 is already transparently supported by owlib. Is it? Last time I checked, slaves behind a DS2409 or two do not show up in "owdir /" or "owdir /bus.0" or "owdir /alarm", they do not notice when I set /simultaneous/temperature, … So either I'm missing something, or your definition of "transparent" differs from mine. :-/ > Not sure what you want to put on top. For one, support for (bus-specific) handling of /alarm or /simultaneous. The idea is that different 1wire buses may have different requirements (timing, polling, alarm handling, how often to trigger temperature conversion, bus re-enumeration, …); it's the client system's job to coordinate the device instances' requirements to do the least-possible amount of work, and only on the bus(es) it cares about. -- -- Matthias Urlichs signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Announcing a new Python library
Am 05.09.2018 um 05:20 schrieb Matthias Urlichs via Owfs-developers: > Hi, > > I'm writing a new high-level asynchronous Python library to talk > to owserver. > > It features multiple persistent server connections, transparent > support for DS2409 couplers, automatic retries when he server is > busy or the connection breaks, object-oriented design, > auto-generating accessor methods for bus slaves (based on the > server's /structure tree), reporting state changes via an async > event stream, and more. > > On the TODO list: auto-polling (both distinct and via > /simultaneous), alarm handling. > > Check it out at: https://github.com/python-trio/trio-owfs > These are nice features, but the real thing is aggregates and logical abstraction. The latter is needed for automatically setting up chips according to the modules they are put on after their power-on. Because power-on and unknown states of remote devices is what happens on a hot-pluggable bus all the time. Alarm handling comes in handy there and can also be used for other purposes. I found that writing a simple class hierachy in Tcl for a project using OWFS, which does roughly what you intend. So my advice from pratice is basing all the automatical mechanisms on a logical abstraction of a whole peripheral, with the Onewire stuff being only a part of a bigger picture. The DS2409 is already transparently supported by owlib. Not sure what you want to put on top. Kind regards Jan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
