I was poking around the owserver protocol from Python to see if a simple standalone python module can be created that doesn't have any dependencies on the core ow libraries. I ran into a bit of a problem with the protocol that's being used. Here's a hex dump of the data that's returned when I request a directory of the root.
00000000: 0000 0000 0000 002a 0000 0000 0000 0102 .......*........ 00000010: 0000 0005 0000 0000 6275 732e 3000 ec28 ........bus.0..( 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000040: 0000 0000 0000 0000 002a 0000 0000 0000 .........*...... 00000050: 0102 0000 0008 0000 0000 7365 7474 696e ..........settin 00000060: 6773 0000 0000 0000 0000 0000 0000 0000 gs.............. 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000080: 0000 0000 0000 0000 0000 002a 0000 0000 ...........*.... 00000090: 0000 0102 0000 0006 0000 0000 7379 7374 ............syst 000000a0: 656d 0000 0000 0000 0000 0000 0000 0000 em.............. 000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000c0: 0000 0000 0000 0000 0000 0000 002a 0000 .............*.. 000000d0: 0000 0000 0102 0000 000a 0000 0000 7374 ..............st 000000e0: 6174 6973 7469 6373 0000 0000 0000 0000 atistics........ 000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000100: 0000 0000 0000 0000 0000 0000 0000 002a ...............* 00000110: 0000 0000 0000 0102 0000 0010 0000 0000 ................ 00000120: 2f31 302e 4237 4236 3444 3030 3038 3030 /10.B7B64D000800 00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000150: 002a 0000 0000 0000 0102 0000 0010 0000 .*.............. 00000160: 0000 2f32 362e 4146 3245 3135 3030 3030 ../26.AF2E150000 00000170: 3030 0000 0000 0000 0000 0000 0000 0000 00.............. 00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000190: 0000 002a 0000 0000 0000 0102 0000 0010 ...*............ 000001a0: 0000 0000 2f38 312e 4134 3443 3233 3030 ..../81.A44C2300 000001b0: 3030 3030 0000 0000 0000 0000 0000 0000 0000............ 000001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001d0: 0000 0000 0000 0000 0000 0000 0102 0000 ................ 000001e0: 0000 0000 c002 ...... It shows (hex - decimal): version: 0x0 - 0 payload length: 0x2a - 42 type: 0x0 - 0 format flags: 0x102 - 258 size of data: 0x5 - 5 offset - 0x0 - 0 The payload doesn't look quite right since there's a whole lot more that's received from the server, 486 bytes total. The size of data seems to correspond to the length of the first entry name w/ trailing null - bus.0. But the rest doesn't make much sense to me. In looking at the hex dump of the data, I see the various values that I would expect in settings, system, statistics, etc. But I also see a whole lot more data that seems to be extra. I tried reading through the C headers and source but had trouble making heads or tails of the code that would be putting the buffer together to send over the network. I'm a wee bit lost here. So if anyone has a good idea of what's going on, let me know. Thanks! - Peter On 12/4/06, Paul Alfille <[EMAIL PROTECTED]> wrote: > Ok, communication is via tcp. > > 1. open port > 2. send a message > 3. wait for response (single response except for directories). > 4. close port > > Message has format: > 6 words (24 bytes) fixed header > variable length "payload" > Words must be sent in network order (bigendian I believe) > Header is: > Version (use 0) > Payload (size of variable length in bytes) > Type (see below) > SG (basically temperature scale) > Size (for writes, size of data portion of payload) > Offset (for reads and writes, usually 0) > Type > 0 error > 1 nop > 2 read > 3 write > 4 dir > 5 size (not used any more) > 6 presence > > Basically, you set up the header, and follow it with payload, and send the > whole thing. > Payload is typically the "path" e.g. /10.12300432433/temperature > Possibly followed with a value for writes. > > You get back about the same thing. The fields are slightly different (error > codes, data length) but the value is in the payload. > > If you want to do this, I'm sure people would be glad to assist. It > certainly sounds like an interesting project. > > Paul Alfille > > > > On 12/4/06, chris <[EMAIL PROTECTED]> wrote: > > On Monday 04 December 2006 12:02, Paul Alfille wrote: > > > On 12/4/06, chris <[EMAIL PROTECTED]> wrote: > > > > I understand that owfs is unlikely to run on windows but is it > possible > > > > to tun > > > > > > Au-contraire! (Though the windows port is not yet of the same quality. > > > There have been reports of memory leaks that need to be investigated). > > > > > > owpython on a windows box connected to owserver without resorting to > > > > > > > > > Ahh! You want to communicate (with owserver?) via python, but not use > the > > > libow library (which builds under cygwin). > > > This has been done for other languages: > > > > > > owshell -- uses C to talk to the owserver directly. Perhaps a little > > > complex, since it includes the Bonjour code and came from a stripped > > > version of libow in the first place. > > > > > > owsim -- a work in progress that uses Tcl to talk to owserver. Tcl has > > > great network support and we essentially parse the owserver protocol in > Tcl > > > code. > > > > > > I suspect that you could do the same in python. Probably a few days > project > > > for a python expert. The owserver network protocol is documented on the > > > website: > http://www.owfs.org/index.php?page=owserver-protocol > > > (And in the code, of course). > > > > > > For TCL > > > network basics: > > > > http://owfs.cvs.sourceforge.net/owfs/owfs/module/simulants/ownet.tcl?revisi > > >on=1.5&view=markup server code: > > > > http://owfs.cvs.sourceforge.net/owfs/owfs/module/simulants/owhandler.tcl?re > > >vision=1.8&view=markup (Note that owsim is a owserver, rather than > client). > > > > > > excellent but rather cumbersome methods like cygwin? > > > > > > > Yep that is the sort of line I'd like to be able to take. I'm very messy > at > > code, but where's theres a will, I'm building a higher object model using > > Django http://www.djangoproject.com which constructs database models from > > python class models. > > > > > > > > > > I am keen to be able to monitor the one wire network in several places > > > > all of > > > > which are windows devices with users who are even more simplistic than > > > > myself > > > > ( if that can be believed, my only defence is that some of them are 6 > > > > years > > > > old) > > > > > > You underestimate your progeny! If they can hack python, they are > probably > > > os agnostic. > > > > They mostly use it to cheat on maths homework. Niether have realised > > multiplication is a lookup. > > > > > > > > owpython seems only to be availabe as an rpm, can I just copy the source > > > > > I really don't want to have to re-write too much cos I'm lazy, and the > more I > > write the more errors I know are there. > > > > A Sensor object is a lovely concept in itself. > > > > > > > I presume you want to display (and perhaps control) your system on > > > distributed computers, with more than one platform. Have you considered > > > building a web app? Your cgi code can use python or bash or whatever. > You > > > can expose whatever you want, even full owhttpd. It would be easier to > > > develope and use a central http server, trusting that all other machines > > > can easily load a browser. > > > > There's an attempt to generate a distributed model for community energy > use > > monitoring that's running out of a forum: > > http://navitron.org.uk/forum/index.php?topic=678.0 > > > > I'm keen to plug into Visual Python for object representations of solar > rigs. > > have a look at http://www.spritenote.co.uk/solar.html for > an idea of what I'm > > up to. > > I've got a pretty awful object model running which might allow auto > assembly > > of this sort of system. > > > > > > > > > > > Besides, we believe in cultural diversity. > > > And we have great sympathy for non-native American speakers. > > > > > > Paul Alfille > > > > Hadn't considered the language implications of the style. And isn't the > > language English :D.. or is it actually written in Navaho? > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > > opinions on IT & business topics through brief surveys - and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Owfs-developers mailing list > > Owfs-developers@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
