1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
solarpowerlog
This file is some random thought collection and gives some ideas what direction
solarpowerlog goes...
ROADMAP
Next Version: (which will probably be version 0.24)
-> Rework of the Sputnik Inverters (complete)
Current version had basically copy-paste code for every command and
was ugly to maintain. The new version encapsulates all commands that
the Sputnik inverter undertands in a set of templated and special
classes.
As a side-effect adding new commands is now (usually) child-play.
-> Sputnik Simulator integrated in solarpowerlog (complete)
The "existing" netcat based inverter was too static, and therefore,
based on the CSputnikInverter a simulator has been embedded.
After compiling with simulator support and configurating it, it will
listen e.g TCP/IP and answer queries from e.g. another instance of
solarpowerlog (or other programms that support the Sputnik Inverters)
Additionally, it will provide a control server, so the answers to the
queries can be tweaked (values changed, commands turned off/on)
-> Improved SIGTERM Handling (complete)
Current versions took some time from SIGTERM to actual termination due
to the internal handling of events (WorkScheduler had to finish a work
before checking the status.) Worst-case syvinit sent SIGKILL before we
handled SIGTERM and this could lead that some buffers are not flushed.
The new handling inserts a "Work" when SIGTERM is received and
therefore actively informing the inverters/datafilters of the imminent
termination, so that appropiate actions can be performded.
-> SharedComms (complete)
SharedComms are still experimental and there are several ugly race-condtions,
especially when receiving data from the inverter.
The problem is that in the time betwen the first read request is completed and
the time until the inverter will request the next one bytes can get lost.
Solution is to introduce some caching, so the SharedComms will always read,
even without an read request and buffer until the inverter actually requests
to read.
-> Comms/Inverter interaction, configuration. (complete)
-> The inverters should specify timeouts, not the communication objects
This allows more fine-grade settings, in respect to context.
=======================================
Scheduled for next+1 versions:
-> Documentation update
solarpowerlog needs some better documentation. The current docs are quite
outdated and incompete.
-> Development documents update
The same for the dev docs
-> Docs are not well maintainable
They are maintained "out of the source" and this is hard to keep in
sync. So bring the docs into the source tree and auto-generate docs at
buildtime
=======================================
open, but no release goal yet:
-> Sputnik Inverter
-> Make the "event log" available, (EC* commands.)
-> Support setting the date/time of the inverters
-> CVS Inverters
-> Specify the time between flushes, not only "flush every time"
-> Configuration System
-> Allow all classes to cache config info and cache them locally in
member variables (as dynamic reconfiguration has been dropped as
design goal)
This should reduce complexity (lower CPU at the cost of memory, but
will increase readability of the code)
-> SQL datafilter
-> JSON/XML output
-> Communication: The cases where callbacks are allowed to be NULL are now gone
Check if deletion of the commands in the task of the ASIO based classes still needs
to be done or if this can be removed.
-> Complete the HTML Writer to allow plotting more than one inverter.
-----------------------------------------------
random ideas....
- Rework the Capability interface, maybe a helper class that will update
the variables by callbacks or by direct accessing members: This is a common
coding for all filters, so having code reuse will might this easier and
better
- witty-application or XML-Request interface (to make some ajaxiation ;-)
- "End of Day" Filter -- for just one dataset reflecting the whole day.
- Adding some other inverters
- additional filters, for monthly, yearly reports, comparisions of inverters, string)
- mail plugin to report errors (or a daily mail)
- reporting not only to mail, but also to *** (e.g. twitter)
- solar weather forecast (there was a post debian-mentors)
|
