[B.A.T.M.A.N.] new alfred packet type *3* for solar tracer charging units

[B.A.T.M.A.N.] new alfred packet type *3* for solar tracer charging units

[Ufo]

at Solarfestival in Germany we were reverse engineering some solar
tracer charge controllers. so they were part of the local wifi mesh
https://twitter.com/rundfreifunk/status/502788487549288448
https://twitter.com/rundfreifunk/status/503888938973802496
https://twitter.com/rundfreifunk/status/503942726292103168

best way for distributing the detailed data (about local sun impact..)
was alfred. we used nr. 160 but now simon choosed nr. 3 for that.

https://twitter.com/rundfreifunk/status/503548243452899328

so, plug your solar systems into your mesh-nodes!

https://twitter.com/rundfreifunk/status/503875891735560192
https://twitter.com/rundfreifunk/status/504575102965792768

greetings, ufo

p.s.

code: https://gitorious.org/tracertools/pages/Home

p.p.s.

anyone with CRC expierence?? please! we need help with that dump CRC,
please have a look if there is a new idea about used crc

http://pad.freifunk.net/p/solartracer


-- 
---
Freifunk Leipzig http://leipzig.freifunk.net

Re: [B.A.T.M.A.N.] new alfred packet type *3* for solar tracer charging units

[Ufo]

Am 27.08.14 15:14, schrieb Ufo:
> best way for distributing the detailed data (about local sun impact..)
> was alfred. we used nr. 160 but now simon choosed nr. 3 for that.

all the different values from solar units are now defined on our test
systems. and meanwhile EP Solar China gave us some additional hints..

https://twitter.com/rundfreifunk/status/519083918436630528
https://gitorious.org/tracertools/tracertools/source/4a6eb477a850e102f37b6f6690b0797ec664f36d:tracerstat.c#L26

so the next step should be to include these into alfred?

-- 
---
Freifunk Leipzig http://leipzig.freifunk.net

Re: [B.A.T.M.A.N.] new alfred packet type *3* for solar tracer charging units

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Monday 06 October 2014 13:28:11 Ufo wrote:
> Am 27.08.14 15:14, schrieb Ufo:
> > best way for distributing the detailed data (about local sun impact..)
> > was alfred. we used nr. 160 but now simon choosed nr. 3 for that.
> 
> all the different values from solar units are now defined on our test
> systems. and meanwhile EP Solar China gave us some additional hints..
> 
> https://twitter.com/rundfreifunk/status/519083918436630528
> https://gitorious.org/tracertools/tracertools/source/4a6eb477a850e102f37b6f6
> 690b0797ec664f36d:tracerstat.c#L26
> 
> so the next step should be to include these into alfred?
We basically have two options here:

 * integrat the tracetools into the alfred repository, similar to vis and 
gpsd. Please note that the quality should also be similar and you or your 
colleagues should be able to maintain that code
 * keep the package external (e.g. on gitorious), then since we have an 
external software package now we should start using a number assignment table 
in wiki to show which software uses which packet type. We could then link from 
there your software

Any preferences? :)

Cheers,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [B.A.T.M.A.N.] new alfred packet type *3* for solar tracer charging units

[Daniel Golle]

On Mon, Oct 06, 2014 at 04:39:15PM +0200, Simon Wunderlich wrote:
> > so the next step should be to include these into alfred?
> We basically have two options here:
> 
>  * integrat the tracetools into the alfred repository, similar to vis and 
> gpsd. Please note that the quality should also be similar and you or your 
> colleagues should be able to maintain that code
>  * keep the package external (e.g. on gitorious), then since we have an 
> external software package now we should start using a number assignment table 
> in wiki to show which software uses which packet type. We could then link from 
> there your software
> 
> Any preferences? :)

I will definitely keep tracertools a standalone software package as there are
many potential use-cases which do not involve alfred.
Basically I'm still in the prototyping progress of a bigger system in,
tracertools was a part of that effort. Now that other things (using PCF8574A
and LTC4151 to monitor and control consumer-grade DC-to-AC inverters via I2C)
also work, I will re-work the whole design, both, in terms of hardware I will
move away from breadboard and loose wires to a proper shield targetting the
WrtNode; in terms of software, tracertools will become a small lib and
include handling serial port stuff instead of depending on socat to do that
(though using socat has a couple of advantages as well and I may keep the
option to pipe stuff through socat).
Packages like collectd and alfred can then use libsolartracer to acquire
(cached) stats or execute control commands on the charge controller, similar
to how libgps is used by alfred.
I'm planning to suggest a patch to alfred to optionally use libsolartracer
when the time has come for that...

Cheers

Daniel

Re: [B.A.T.M.A.N.] new alfred packet type *3* for solar tracer charging units

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]

On Monday 06 October 2014 23:04:28 Daniel Golle wrote:
> On Mon, Oct 06, 2014 at 04:39:15PM +0200, Simon Wunderlich wrote:
> > > so the next step should be to include these into alfred?
> > 
> > We basically have two options here:
> >  * integrat the tracetools into the alfred repository, similar to vis and
> > 
> > gpsd. Please note that the quality should also be similar and you or your
> > colleagues should be able to maintain that code
> > 
> >  * keep the package external (e.g. on gitorious), then since we have an
> > 
> > external software package now we should start using a number assignment
> > table in wiki to show which software uses which packet type. We could
> > then link from there your software
> > 
> > Any preferences? :)
> 
> I will definitely keep tracertools a standalone software package as there
> are many potential use-cases which do not involve alfred.
> Basically I'm still in the prototyping progress of a bigger system in,
> tracertools was a part of that effort. Now that other things (using PCF8574A
> and LTC4151 to monitor and control consumer-grade DC-to-AC inverters via
> I2C) also work, I will re-work the whole design, both, in terms of hardware
> I will move away from breadboard and loose wires to a proper shield
> targetting the WrtNode; in terms of software, tracertools will become a
> small lib and include handling serial port stuff instead of depending on
> socat to do that (though using socat has a couple of advantages as well and
> I may keep the option to pipe stuff through socat).
> Packages like collectd and alfred can then use libsolartracer to acquire
> (cached) stats or execute control commands on the charge controller, similar
> to how libgps is used by alfred.
> I'm planning to suggest a patch to alfred to optionally use libsolartracer
> when the time has come for that...

OK, so at some point you'll probably write an alfred patch which goes into our 
repo and will make use of  your library? That sounds like a good approach to 
me ... :)

Thank you very much for the feedback, please keep us posted on your 
proceedings!!

Thanks,
    Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]