Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Andreas Goetz]

Hallo Zusammen,

ich hab gerade https://github.com/volkszaehler/volkszaehler.org/pull/630 
 committed- php7 ist 
ab jetzt für die Composer Installation notwendig.

Darüber kann man sich per Composer Kommandozeile noch hinwegsetzen 
(—ignore-platform-reqs), dann fehlt allerdings das Exception Handling da 
\Throwable auf php5 nicht existiert.

Ich würde sagen wir lassen das jetzt mal ein paar Tage ruhen. Falls es auf der 
ML einen Aufschrei geben sollte sagt mir bitte Bescheid.

Viele Grüße, 
Andreas

> On 9. Sep 2017, at 20:04, Justin Otherguy  wrote:
> 
> Moin,
> 
> habe vorhin mal g’schwind(tm) demo.volkszaehler.org von jessie auf stretch 
> angehoben; war ziemlich schmerzfrei (phpmyadmin hat um Neuinstallation 
> gebeten).
> 
> Aus meiner Sicht läuft nun alles wieder rund - ich bitte um Hinweise, falls 
> Euch Fehler in der Matrix auffallen.
> 
> 
> Gruß, J.
> 
>> Am 09.09.2017 um 12:21 schrieb Andreas Goetz :
>> 
>> Hallo Zusammen,
>> 
>> seit einiger Zeit war es möglich PHP7 auf Debian/Raspbian jessie zu 
>> installieren. Seit auch Raspian bei stretch angekommen ist ist PHP7 
>> standardmäßig verfügbar. Die Programmierung mittels PHP7 ist an vielen 
>> Stellen angenehmer als mit 5.6.
>> 
>> Was haltet ihr davon den aktuellen Stand der Repositories als Version zu 
>> releasen (kein Changelog, da ist so viel passiert) und dann composer und 
>> travis auf PHP7 umzustellen? Ab diesem Zeitpunkt wird keine Installation auf 
>> 5.6 mehr möglich sein.
>> 
>> Wie seht ihr das?
>> 
>> Viele Grüße, Andreas
> 
> 

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Udo1]

Vielleicht hilft das weiter:

https://github.com/Fourdee/DietPi/issues/1077

Gruß
Udo

Am 15.09.2017 um 12:46 schrieb Frank Richter:

Hab ich versucht:

root@bananapi ~ # apt-get install php-apcu
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Package php-apcu is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'php-apcu' has no installation candidate


Grüße
Frank

Am 15. September 2017 um 12:27 schrieb Andreas Goetz >:


apcu bringt einen Tick Performance, habs aber nie gemessen. Bei
Performance Middleware vmtl. irrelevant. Laut
https://packages.debian.org/stretch/php-apcu
 müsste das php-apcu
heißen.

Viele Grüße, Andreas



On 15. Sep 2017, at 11:59, Frank Richter
> wrote:

Hi,

auch von mir nochmal was zum ursprünglichen Thema: der Banana Pro
hat jetzt PHP 7.0, die Middleware scheint auch problemlos zu
laufen. Also von hier grünes Licht für Wegfall von PHP 5.6 Support.
Was ich jetzt auf die Schnelle nicht geschafft hab, ist die
Installation von php7.0-apcu, das findet er nicht. Wichtig für vz?

Grüße
Frank

Am 11. September 2017 um 09:43 schrieb Andreas Goetz
>:

Hi Frank,

mit dem Banana kenne ich mich nicht aus. Prinzipiell könntest
man aber auch die stretch Quellen hinzuführen und von dort
installieren:

    apt install -t stretch php7

Dazu in /etc/apt/preferences sicherstellen dass stretch dort
mit priority 10 (statt 500 für jessie) auftaucht.

Falls die Raspian Binaries prinzipiell auf dem Banana laufen
(ist ja alles die gleiche ARM Architktur?) dann sollte das
gehen. Dich würde ich jedenfalls sehr ungern als Cheftester
verlieren ;)

Viele Grüße,
Andreas

2017-09-10 12:42 GMT+02:00 Frank Richter
>:

Hi Andreas,

wenn es für die Entwicklung Vorteile bringt und auf dem
RPi ohne Klimmzüge läuft, machen!
Ich müsste dann nur mal schauen, ob ich meinem Banana Pro
(jessie) auch PHP 7 beibringen kann. Mit stretch ist da
leider nicht zu rechnen.

Grüße
Frank

Am 09.09.2017 12:22 schrieb "Andreas Goetz"
>:

Hallo Zusammen,

seit einiger Zeit war es möglich PHP7 auf
Debian/Raspbian jessie zu installieren. Seit auch
Raspian bei stretch angekommen ist ist PHP7
standardmäßig verfügbar. Die Programmierung mittels
PHP7 ist an vielen Stellen angenehmer als mit 5.6.

Was haltet ihr davon den aktuellen Stand der
Repositories als Version zu releasen (kein Changelog,
da ist so viel passiert) und dann composer und
travis auf PHP7 umzustellen? Ab diesem Zeitpunkt wird
keine Installation auf 5.6 mehr möglich sein.

Wie seht ihr das?

Viele Grüße, Andreas

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Frank Richter]

Hab ich versucht:

root@bananapi ~ # apt-get install php-apcu
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Package php-apcu is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'php-apcu' has no installation candidate


Grüße
Frank

Am 15. September 2017 um 12:27 schrieb Andreas Goetz :

> apcu bringt einen Tick Performance, habs aber nie gemessen. Bei
> Performance Middleware vmtl. irrelevant. Laut https://packages.debian.
> org/stretch/php-apcu müsste das php-apcu heißen.
>
> Viele Grüße, Andreas
>
>
> On 15. Sep 2017, at 11:59, Frank Richter 
> wrote:
>
> Hi,
>
> auch von mir nochmal was zum ursprünglichen Thema: der Banana Pro hat
> jetzt PHP 7.0, die Middleware scheint auch problemlos zu laufen. Also von
> hier grünes Licht für Wegfall von PHP 5.6 Support.
> Was ich jetzt auf die Schnelle nicht geschafft hab, ist die Installation
> von php7.0-apcu, das findet er nicht. Wichtig für vz?
>
> Grüße
> Frank
>
> Am 11. September 2017 um 09:43 schrieb Andreas Goetz :
>
>> Hi Frank,
>>
>> mit dem Banana kenne ich mich nicht aus. Prinzipiell könntest man aber
>> auch die stretch Quellen hinzuführen und von dort installieren:
>>
>> apt install -t stretch php7
>>
>> Dazu in /etc/apt/preferences sicherstellen dass stretch dort mit priority
>> 10 (statt 500 für jessie) auftaucht.
>>
>> Falls die Raspian Binaries prinzipiell auf dem Banana laufen (ist ja
>> alles die gleiche ARM Architktur?) dann sollte das gehen. Dich würde ich
>> jedenfalls sehr ungern als Cheftester verlieren ;)
>>
>> Viele Grüße,
>> Andreas
>>
>> 2017-09-10 12:42 GMT+02:00 Frank Richter :
>>
>>> Hi Andreas,
>>>
>>> wenn es für die Entwicklung Vorteile bringt und auf dem RPi ohne
>>> Klimmzüge läuft, machen!
>>> Ich müsste dann nur mal schauen, ob ich meinem Banana Pro (jessie) auch
>>> PHP 7 beibringen kann. Mit stretch ist da leider nicht zu rechnen.
>>>
>>> Grüße
>>> Frank
>>>
>>> Am 09.09.2017 12:22 schrieb "Andreas Goetz" :
>>>
 Hallo Zusammen,

 seit einiger Zeit war es möglich PHP7 auf Debian/Raspbian jessie zu
 installieren. Seit auch Raspian bei stretch angekommen ist ist PHP7
 standardmäßig verfügbar. Die Programmierung mittels PHP7 ist an vielen
 Stellen angenehmer als mit 5.6.

 Was haltet ihr davon den aktuellen Stand der Repositories als Version
 zu releasen (kein Changelog, da ist so viel passiert) und dann composer
 und travis auf PHP7 umzustellen? Ab diesem Zeitpunkt wird keine
 Installation auf 5.6 mehr möglich sein.

 Wie seht ihr das?

 Viele Grüße, Andreas


>>
>
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Andreas Goetz]

apcu bringt einen Tick Performance, habs aber nie gemessen. Bei Performance 
Middleware vmtl. irrelevant. Laut https://packages.debian.org/stretch/php-apcu 
 müsste das php-apcu heißen.

Viele Grüße, Andreas


> On 15. Sep 2017, at 11:59, Frank Richter  wrote:
> 
> Hi,
> 
> auch von mir nochmal was zum ursprünglichen Thema: der Banana Pro hat jetzt 
> PHP 7.0, die Middleware scheint auch problemlos zu laufen. Also von hier 
> grünes Licht für Wegfall von PHP 5.6 Support.
> Was ich jetzt auf die Schnelle nicht geschafft hab, ist die Installation von 
> php7.0-apcu, das findet er nicht. Wichtig für vz?
> 
> Grüße
> Frank
> 
> Am 11. September 2017 um 09:43 schrieb Andreas Goetz  >:
> Hi Frank,
> 
> mit dem Banana kenne ich mich nicht aus. Prinzipiell könntest man aber auch 
> die stretch Quellen hinzuführen und von dort installieren:
> 
> apt install -t stretch php7
> 
> Dazu in /etc/apt/preferences sicherstellen dass stretch dort mit priority 10 
> (statt 500 für jessie) auftaucht. 
> 
> Falls die Raspian Binaries prinzipiell auf dem Banana laufen (ist ja alles 
> die gleiche ARM Architktur?) dann sollte das gehen. Dich würde ich jedenfalls 
> sehr ungern als Cheftester verlieren ;)
> 
> Viele Grüße,
> Andreas
> 
> 2017-09-10 12:42 GMT+02:00 Frank Richter  >:
> Hi Andreas,
> 
> wenn es für die Entwicklung Vorteile bringt und auf dem RPi ohne Klimmzüge 
> läuft, machen!
> Ich müsste dann nur mal schauen, ob ich meinem Banana Pro (jessie) auch PHP 7 
> beibringen kann. Mit stretch ist da leider nicht zu rechnen.
> 
> Grüße
> Frank
> 
> Am 09.09.2017 12:22 schrieb "Andreas Goetz"  >:
> Hallo Zusammen,
> 
> seit einiger Zeit war es möglich PHP7 auf Debian/Raspbian jessie zu 
> installieren. Seit auch Raspian bei stretch angekommen ist ist PHP7 
> standardmäßig verfügbar. Die Programmierung mittels PHP7 ist an vielen 
> Stellen angenehmer als mit 5.6.
> 
> Was haltet ihr davon den aktuellen Stand der Repositories als Version zu 
> releasen (kein Changelog, da ist so viel passiert) und dann composer und 
> travis auf PHP7 umzustellen? Ab diesem Zeitpunkt wird keine Installation auf 
> 5.6 mehr möglich sein.
> 
> Wie seht ihr das?
> 
> Viele Grüße, Andreas
> 
> 
> 

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Frank Richter]

Hi,

auch von mir nochmal was zum ursprünglichen Thema: der Banana Pro hat jetzt
PHP 7.0, die Middleware scheint auch problemlos zu laufen. Also von hier
grünes Licht für Wegfall von PHP 5.6 Support.
Was ich jetzt auf die Schnelle nicht geschafft hab, ist die Installation
von php7.0-apcu, das findet er nicht. Wichtig für vz?

Grüße
Frank

Am 11. September 2017 um 09:43 schrieb Andreas Goetz :

> Hi Frank,
>
> mit dem Banana kenne ich mich nicht aus. Prinzipiell könntest man aber
> auch die stretch Quellen hinzuführen und von dort installieren:
>
> apt install -t stretch php7
>
> Dazu in /etc/apt/preferences sicherstellen dass stretch dort mit priority
> 10 (statt 500 für jessie) auftaucht.
>
> Falls die Raspian Binaries prinzipiell auf dem Banana laufen (ist ja alles
> die gleiche ARM Architktur?) dann sollte das gehen. Dich würde ich
> jedenfalls sehr ungern als Cheftester verlieren ;)
>
> Viele Grüße,
> Andreas
>
> 2017-09-10 12:42 GMT+02:00 Frank Richter :
>
>> Hi Andreas,
>>
>> wenn es für die Entwicklung Vorteile bringt und auf dem RPi ohne
>> Klimmzüge läuft, machen!
>> Ich müsste dann nur mal schauen, ob ich meinem Banana Pro (jessie) auch
>> PHP 7 beibringen kann. Mit stretch ist da leider nicht zu rechnen.
>>
>> Grüße
>> Frank
>>
>> Am 09.09.2017 12:22 schrieb "Andreas Goetz" :
>>
>>> Hallo Zusammen,
>>>
>>> seit einiger Zeit war es möglich PHP7 auf Debian/Raspbian jessie zu
>>> installieren. Seit auch Raspian bei stretch angekommen ist ist PHP7
>>> standardmäßig verfügbar. Die Programmierung mittels PHP7 ist an vielen
>>> Stellen angenehmer als mit 5.6.
>>>
>>> Was haltet ihr davon den aktuellen Stand der Repositories als Version zu
>>> releasen (kein Changelog, da ist so viel passiert) und dann composer
>>> und travis auf PHP7 umzustellen? Ab diesem Zeitpunkt wird keine
>>> Installation auf 5.6 mehr möglich sein.
>>>
>>> Wie seht ihr das?
>>>
>>> Viele Grüße, Andreas
>>>
>>>
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Daniel Lauckner]

Hallo,


am Donnerstag, 14. September 2017 um 11:32 hat Andreas Goetz geschrieben:
> bevor es völlig off-topic wird mein Verständnis: ja, php5.6 können
> wir fallen lassen. D.h. ich release nochmal den aktuellen Stand als
> v0.6, ziehe einen release Branch für eventuelle Hotfixes und darf dann 
> umbauen.

Von mir aus gern.


mfg Daniel

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[F. S.]

Am 14.09.2017 19:55 schrieb "Frank Richter" :

Am 14. September 2017 um 18:56 schrieb F. S. :

>
> Am 14. September 2017 um 17:39 schrieb Frank Richter <
> frank.richte...@gmail.com>:
>
>> Am 14. September 2017 um 15:32 schrieb F. S. 
>> :
>>
>>> Moin,
>>> nur kurz zum SDM630:
>>>
>>>
>>> Du weißt dass die Import-/Export-Zählwerke beim SDM630 nicht
>> phasensaldierend arbeiten?
>>
>
> Nein? Muss mich das bei virtuellen Kanälen aber interessieren?
>

 Wenn du auf 2 Phasen Überschuss und auf einer Bezug hast, ändern sich
 beide Zählerstände (Import und Export). Du loggst also Bezug und
 Einspeisung, die beim saldierenden Zähler unter den Tisch fallen. Ist IMHO
 nicht trivial, das wieder rauszurechnen.

>>>
>>> Ich würde nur die *Leistungen *der 3 Phasen aller 1-2s messen und die
>>> Zählerstände (kWh) selbst summieren. Für eine Eigenverbrauchsregelung mit
>>> annähernd Nullbezug braucht es m.E. nur die Leistungen. Für's Archivlogging
>>> dann die errechneten Zählerstände, die durchaus ausgedünnt sein können.
>>> Ansonsten ist der Zähler top - vor allem der SDM630_v2 mit verbesserten
>>> Anschlüssen. Für 80$ auch noch unschlagbar günstig.
>>>
>>
>> Für Regelungszwecke passen die Momentanleistungen besser, soweit klar.
>> Für Verbrauchsbetrachtungen über längere Zeiträume find ich Zählerstände
>> aber schöner, weil dann der Zähler die Integration übernimmt. Der macht das
>> wahrscheinlich exakter als vz, wo wir davon ausgehen müssen, dass die
>> Leistung zwischen 2 Messwerten konstant ist.
>>
>
> Ist klar Frank.
> Bei mir hat die Ausregelung auf Null gerade absoluten Vorrang. Ev. wirft
> man diese Leistungsdaten dann auch gleich weg und verwendet die
> integrierten Zählersummen Imp/Exp, um zum gesamtheitlichen (saldierten)
> Bezug oder Überschuss für die Archivierung zu kommen. Dafür müssten dann in
> den gewünschten Zeitabständen die 2 (Imp / Exp) + 3 Phasen = 6
> Modbus-Register für L1...L3 (kWh) ausgelesen und summiert werden. Das
> dürfte nicht so schwierig sein. Beim neueren SDM630_v2 müssten das diese
> sein:
>
> 30347 174 L1 import kWh 01 5a
> 30349 175 L2 import kWh 01 5c
> 30351 176 L3 import kWh 01 5e
>
> 30353 177 L1 export kWh 01 60
> 30355 178 L2 export kWh  01 62
> 30357 179 L3 export kWh 01 64
>

Ein letztes OT noch: um aus den Zählerständen von L1 - L3 phasensaldierte
Werte für Bezug und Einspeisung zu gewinnen, reicht es nicht, diese im
gewünschten Logging-Intervall auszulesen und zu verrechnen, weil in den
Werten keine Information über die Gleichzeitigkeit der Energieflüsse
steckt. Sauber rechnen lässt sich das nur, wenn man das in sehr hoher
Zeitauflösung macht. Dann braucht man aber nicht zwingend die Werte der
einzelnen Phasen, sondern es genügen auch die Summen von Import und Export.
Nachteilig für diese Berechnung ist die begrenzte Auflösung der
ausgelesenen Zählerstände. Ich hab bisher nur mit einem SDM120 rumgespielt,
der lieferte Energie in Auflösung 1Wh. Ist das beim SDM630 (v2) genauso?

Grüße
Frank


Ja, für ein zählerstandsbasiertes saldierendes Energie-/Arbeitslogging
würde ich das so machen:
 (sum_Imp_act + sum_Exp_act - (sum_Imp_old + sum_Exp_old)) / Zeitintervall
=> müsste dann eine gemittelte Leistungsanzeige über den Zeitintervall sein

Je größer der Intervall, desto mehr profitiert man von der zählereigenen
Integration, aber desto gröber fallen die log-Anzeigen aus (Sprünge). Daher
bei Regelungen besser gleich die Leistungen verwenden und die P-Werte dann
verwerfen.

1Wh am Zähler finde ich schon ziemlich genau. Ich bin noch bei den ersten
Ausleseversuchen, aber viel genauer, denke ich, wird's nicht. Fürs Loggen
müssten doch 10s- bis 60s-Intervalle reichen.

VG
Frank S.



> Ich bin jetzt raus - hier geht's ja um was ganz anderes / wichtigers.
> Weiter im PV-Forum.
>
> *Zwischendurch mal ein großes Dankeschön an alle VZ-developer!!! Ich
> verstehe hier zwar nur 30%, dafür ist's ja auch die dev-liste.*
> VG
> Frank S.
>
>
>> Grüße
>> Frank
>>
>
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Frank Richter]

Am 14. September 2017 um 18:56 schrieb F. S. :

>
> Am 14. September 2017 um 17:39 schrieb Frank Richter <
> frank.richte...@gmail.com>:
>
>> Am 14. September 2017 um 15:32 schrieb F. S. 
>> :
>>
>>> Moin,
>>> nur kurz zum SDM630:
>>>
>>>
>>> Du weißt dass die Import-/Export-Zählwerke beim SDM630 nicht
>> phasensaldierend arbeiten?
>>
>
> Nein? Muss mich das bei virtuellen Kanälen aber interessieren?
>

 Wenn du auf 2 Phasen Überschuss und auf einer Bezug hast, ändern sich
 beide Zählerstände (Import und Export). Du loggst also Bezug und
 Einspeisung, die beim saldierenden Zähler unter den Tisch fallen. Ist IMHO
 nicht trivial, das wieder rauszurechnen.

>>>
>>> Ich würde nur die *Leistungen *der 3 Phasen aller 1-2s messen und die
>>> Zählerstände (kWh) selbst summieren. Für eine Eigenverbrauchsregelung mit
>>> annähernd Nullbezug braucht es m.E. nur die Leistungen. Für's Archivlogging
>>> dann die errechneten Zählerstände, die durchaus ausgedünnt sein können.
>>> Ansonsten ist der Zähler top - vor allem der SDM630_v2 mit verbesserten
>>> Anschlüssen. Für 80$ auch noch unschlagbar günstig.
>>>
>>
>> Für Regelungszwecke passen die Momentanleistungen besser, soweit klar.
>> Für Verbrauchsbetrachtungen über längere Zeiträume find ich Zählerstände
>> aber schöner, weil dann der Zähler die Integration übernimmt. Der macht das
>> wahrscheinlich exakter als vz, wo wir davon ausgehen müssen, dass die
>> Leistung zwischen 2 Messwerten konstant ist.
>>
>
> Ist klar Frank.
> Bei mir hat die Ausregelung auf Null gerade absoluten Vorrang. Ev. wirft
> man diese Leistungsdaten dann auch gleich weg und verwendet die
> integrierten Zählersummen Imp/Exp, um zum gesamtheitlichen (saldierten)
> Bezug oder Überschuss für die Archivierung zu kommen. Dafür müssten dann in
> den gewünschten Zeitabständen die 2 (Imp / Exp) + 3 Phasen = 6
> Modbus-Register für L1...L3 (kWh) ausgelesen und summiert werden. Das
> dürfte nicht so schwierig sein. Beim neueren SDM630_v2 müssten das diese
> sein:
>
> 30347 174 L1 import kWh 01 5a
> 30349 175 L2 import kWh 01 5c
> 30351 176 L3 import kWh 01 5e
>
> 30353 177 L1 export kWh 01 60
> 30355 178 L2 export kWh  01 62
> 30357 179 L3 export kWh 01 64
>

Ein letztes OT noch: um aus den Zählerständen von L1 - L3 phasensaldierte
Werte für Bezug und Einspeisung zu gewinnen, reicht es nicht, diese im
gewünschten Logging-Intervall auszulesen und zu verrechnen, weil in den
Werten keine Information über die Gleichzeitigkeit der Energieflüsse
steckt. Sauber rechnen lässt sich das nur, wenn man das in sehr hoher
Zeitauflösung macht. Dann braucht man aber nicht zwingend die Werte der
einzelnen Phasen, sondern es genügen auch die Summen von Import und Export.
Nachteilig für diese Berechnung ist die begrenzte Auflösung der
ausgelesenen Zählerstände. Ich hab bisher nur mit einem SDM120 rumgespielt,
der lieferte Energie in Auflösung 1Wh. Ist das beim SDM630 (v2) genauso?

Grüße
Frank


> Ich bin jetzt raus - hier geht's ja um was ganz anderes / wichtigers.
> Weiter im PV-Forum.
>
> *Zwischendurch mal ein großes Dankeschön an alle VZ-developer!!! Ich
> verstehe hier zwar nur 30%, dafür ist's ja auch die dev-liste.*
> VG
> Frank S.
>
>
>> Grüße
>> Frank
>>
>
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[F. S.]

Am 14. September 2017 um 17:39 schrieb Frank Richter <
frank.richte...@gmail.com>:

> Am 14. September 2017 um 15:32 schrieb F. S. :
>
>> Moin,
>> nur kurz zum SDM630:
>>
>>
>> Du weißt dass die Import-/Export-Zählwerke beim SDM630 nicht
> phasensaldierend arbeiten?
>

 Nein? Muss mich das bei virtuellen Kanälen aber interessieren?

>>>
>>> Wenn du auf 2 Phasen Überschuss und auf einer Bezug hast, ändern sich
>>> beide Zählerstände (Import und Export). Du loggst also Bezug und
>>> Einspeisung, die beim saldierenden Zähler unter den Tisch fallen. Ist IMHO
>>> nicht trivial, das wieder rauszurechnen.
>>>
>>
>> Ich würde nur die *Leistungen *der 3 Phasen aller 1-2s messen und die
>> Zählerstände (kWh) selbst summieren. Für eine Eigenverbrauchsregelung mit
>> annähernd Nullbezug braucht es m.E. nur die Leistungen. Für's Archivlogging
>> dann die errechneten Zählerstände, die durchaus ausgedünnt sein können.
>> Ansonsten ist der Zähler top - vor allem der SDM630_v2 mit verbesserten
>> Anschlüssen. Für 80$ auch noch unschlagbar günstig.
>>
>
> Für Regelungszwecke passen die Momentanleistungen besser, soweit klar. Für
> Verbrauchsbetrachtungen über längere Zeiträume find ich Zählerstände aber
> schöner, weil dann der Zähler die Integration übernimmt. Der macht das
> wahrscheinlich exakter als vz, wo wir davon ausgehen müssen, dass die
> Leistung zwischen 2 Messwerten konstant ist.
>

Ist klar Frank.
Bei mir hat die Ausregelung auf Null gerade absoluten Vorrang. Ev. wirft
man diese Leistungsdaten dann auch gleich weg und verwendet die
integrierten Zählersummen Imp/Exp, um zum gesamtheitlichen (saldierten)
Bezug oder Überschuss für die Archivierung zu kommen. Dafür müssten dann in
den gewünschten Zeitabständen die 2 (Imp / Exp) + 3 Phasen = 6
Modbus-Register für L1...L3 (kWh) ausgelesen und summiert werden. Das
dürfte nicht so schwierig sein. Beim neueren SDM630_v2 müssten das diese
sein:

30347 174 L1 import kWh 01 5a
30349 175 L2 import kWh 01 5c
30351 176 L3 import kWh 01 5e

30353 177 L1 export kWh 01 60
30355 178 L2 export kWh  01 62
30357 179 L3 export kWh 01 64

Ich bin jetzt raus - hier geht's ja um was ganz anderes / wichtigers.
Weiter im PV-Forum.

*Zwischendurch mal ein großes Dankeschön an alle VZ-developer!!! Ich
verstehe hier zwar nur 30%, dafür ist's ja auch die dev-liste.*
VG
Frank S.


> Grüße
> Frank
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Frank Richter]

Am 14. September 2017 um 15:32 schrieb F. S. :

> Moin,
> nur kurz zum SDM630:
>
>
> Du weißt dass die Import-/Export-Zählwerke beim SDM630 nicht
 phasensaldierend arbeiten?

>>>
>>> Nein? Muss mich das bei virtuellen Kanälen aber interessieren?
>>>
>>
>> Wenn du auf 2 Phasen Überschuss und auf einer Bezug hast, ändern sich
>> beide Zählerstände (Import und Export). Du loggst also Bezug und
>> Einspeisung, die beim saldierenden Zähler unter den Tisch fallen. Ist IMHO
>> nicht trivial, das wieder rauszurechnen.
>>
>
> Ich würde nur die *Leistungen *der 3 Phasen aller 1-2s messen und die
> Zählerstände (kWh) selbst summieren. Für eine Eigenverbrauchsregelung mit
> annähernd Nullbezug braucht es m.E. nur die Leistungen. Für's Archivlogging
> dann die errechneten Zählerstände, die durchaus ausgedünnt sein können.
> Ansonsten ist der Zähler top - vor allem der SDM630_v2 mit verbesserten
> Anschlüssen. Für 80$ auch noch unschlagbar günstig.
>

Für Regelungszwecke passen die Momentanleistungen besser, soweit klar. Für
Verbrauchsbetrachtungen über längere Zeiträume find ich Zählerstände aber
schöner, weil dann der Zähler die Integration übernimmt. Der macht das
wahrscheinlich exakter als vz, wo wir davon ausgehen müssen, dass die
Leistung zwischen 2 Messwerten konstant ist.

Grüße
Frank

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[F. S.]

Moin,
nur kurz zum SDM630:


Du weißt dass die Import-/Export-Zählwerke beim SDM630 nicht
>>> phasensaldierend arbeiten?
>>>
>>
>> Nein? Muss mich das bei virtuellen Kanälen aber interessieren?
>>
>
> Wenn du auf 2 Phasen Überschuss und auf einer Bezug hast, ändern sich
> beide Zählerstände (Import und Export). Du loggst also Bezug und
> Einspeisung, die beim saldierenden Zähler unter den Tisch fallen. Ist IMHO
> nicht trivial, das wieder rauszurechnen.
>

Ich würde nur die *Leistungen *der 3 Phasen aller 1-2s messen und die
Zählerstände (kWh) selbst summieren. Für eine Eigenverbrauchsregelung mit
annähernd Nullbezug braucht es m.E. nur die Leistungen. Für's Archivlogging
dann die errechneten Zählerstände, die durchaus ausgedünnt sein können.
Ansonsten ist der Zähler top - vor allem der SDM630_v2 mit verbesserten
Anschlüssen. Für 80$ auch noch unschlagbar günstig.

>
>
>> PS bzgl. 'next' Features: Ich bastele gerade an einem Feature das es
>>> erlauben würde eigene, komplexere Funktionen auf Basis der Middleware zu
>>> implementieren. Konkret denke ich dabei z.B. an einen Batteriespeicher der
>>> sich damit aufgrund des bekannten Istprofils (Einspeisung + Netzbezug)
>>> simulieren und visualisieren ließe. Geht natürlich auch alles in Excel aber
>>> mit Visualisierung der Lastgänge mit und ohne Speicher fand ich einfach
>>> spannender.
>>>
>>>
>>> Sehr geil! Kann man da schon was testen? Läuft das dann auf den
>>> vollständigen (nicht aggregierten) Daten?
>>>
>>
>> Nein + Ja. Ich brauche erst https://github.com/volkszaehle
>> r/volkszaehler.org/pull/626 als vernünftige Basis für eine Integration-
>> es gibt zuviel gewachsenen Code der aufgeräumt werden muss.
>>
>> Bin gerade dabei Komponenten für ein kleines
>>> Selbstbau-Speicher-Experiment zusammenzusuchen. Eine Simulation
>>> für verschiedene Leistungen des Batteriewechselrichters könnte ich gut
>>> brauchen.
>>>
>>
>> Mein Speichermodell ist ziemlich simpel: Kapazität, min/max
>> Entladng/Ladung und Effizienz. Also Ausgänge gibt es Lade- und
>> Entladeleistung womit sich die Eingangskanäle (Bezug und Lieferung) wieder
>> korrigieren lassen. Im Ergebnis können alle Batterieparameter also auch die
>> Ein- Ausgangskanäle geplottet werden.
>>
>> Wenns fertig ist poste ich im PV Forum dazu.
>>
>
> Hört sich gut an, bin gespannt!
>

me too.
VG Frank S.

>
> Viele Grüße
> Frank
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Frank Richter]

Hi Andreas,

Am 14. September 2017 um 11:32 schrieb Andreas Goetz :

> Moin,
>
> bevor es völlig off-topic wird mein Verständnis: ja, php5.6 können wir
> fallen lassen. D.h. ich release nochmal den aktuellen Stand als v0.6, ziehe
> einen release Branch für eventuelle Hotfixes und darf dann umbauen.
>
> Das wird allerdings dazu führen dass es nach git pull (was man als noob
> ohnehin nicht machen sollte!) Überraschungen geben wird. Die lassen sich
> aber mit git reset --hard  zurück drehen, ist also auch kein
> großer Beinbruch.
>

+1


> Du weißt dass die Import-/Export-Zählwerke beim SDM630 nicht
>> phasensaldierend arbeiten?
>>
>
> Nein? Muss mich das bei virtuellen Kanälen aber interessieren?
>

Wenn du auf 2 Phasen Überschuss und auf einer Bezug hast, ändern sich beide
Zählerstände (Import und Export). Du loggst also Bezug und Einspeisung, die
beim saldierenden Zähler unter den Tisch fallen. Ist IMHO nicht trivial,
das wieder rauszurechnen.


> PS bzgl. 'next' Features: Ich bastele gerade an einem Feature das es
>> erlauben würde eigene, komplexere Funktionen auf Basis der Middleware zu
>> implementieren. Konkret denke ich dabei z.B. an einen Batteriespeicher der
>> sich damit aufgrund des bekannten Istprofils (Einspeisung + Netzbezug)
>> simulieren und visualisieren ließe. Geht natürlich auch alles in Excel aber
>> mit Visualisierung der Lastgänge mit und ohne Speicher fand ich einfach
>> spannender.
>>
>>
>> Sehr geil! Kann man da schon was testen? Läuft das dann auf den
>> vollständigen (nicht aggregierten) Daten?
>>
>
> Nein + Ja. Ich brauche erst https://github.com/
> volkszaehler/volkszaehler.org/pull/626 als vernünftige Basis für eine
> Integration- es gibt zuviel gewachsenen Code der aufgeräumt werden muss.
>
> Bin gerade dabei Komponenten für ein kleines Selbstbau-Speicher-Experiment
>> zusammenzusuchen. Eine Simulation
>> für verschiedene Leistungen des Batteriewechselrichters könnte ich gut
>> brauchen.
>>
>
> Mein Speichermodell ist ziemlich simpel: Kapazität, min/max
> Entladng/Ladung und Effizienz. Also Ausgänge gibt es Lade- und
> Entladeleistung womit sich die Eingangskanäle (Bezug und Lieferung) wieder
> korrigieren lassen. Im Ergebnis können alle Batterieparameter also auch die
> Ein- Ausgangskanäle geplottet werden.
>
> Wenns fertig ist poste ich im PV Forum dazu.
>

Hört sich gut an, bin gespannt!

Viele Grüße
Frank

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Andreas Goetz]

Moin,

bevor es völlig off-topic wird mein Verständnis: ja, php5.6 können wir
fallen lassen. D.h. ich release nochmal den aktuellen Stand als v0.6, ziehe
einen release Branch für eventuelle Hotfixes und darf dann umbauen.

Das wird allerdings dazu führen dass es nach git pull (was man als noob
ohnehin nicht machen sollte!) Überraschungen geben wird. Die lassen sich
aber mit git reset --hard  zurück drehen, ist also auch kein
großer Beinbruch.


2017-09-11 18:09 GMT+02:00 Frank Richter :

> ..
>
>
> Was ich am Raspi3 bzw. an Raspbian mag ist die Fähigkeit zum Netboot.
> Prinzipiell sollte das ja mit DietPi auch möglich sein wenn der (boot
> kernel?) alles Notwendige mitbringt- ich konnte aber nicht rausfinden ob
> das tatsächlich jemandem gelungen ist (http://dietpi.com/phpbb/viewt
> opic.php?f=12=1293).
>
>
> Der Banana Pro hat ja SATA on board, daran habe ich ne kleine SSD und
> seitdem keinen Ärger mehr mit Speicherkarten. Deshalb hab ich mich an
> Netboot noch nicht versucht. Das wär was für meine 3 Pi in den
> Zählerkästen, auf denen nur vzlogger läuft. Aber die sind leider alle aus
> der 1. Raspi-Generation, und Netboot geht soweit ich weiß nur beim Pi 3.
>

M.W. geht das auf dem Raspi1 "fast". D.h. Du brauchst eine SD Karte mit der
/boot Partition (fat). Darauf ist der notwendige Kernel enthalten um den
Netboot durchzuführen. Das Setup hatte ich bei meinen ersten Experimenten
mit der Fritzbox auch bis ich dnsmasq auf dem Server richtig konfiguriert
hatte. Auf die SD wird dann nciht geschrieben, sollte also ewig halten.

Cool, dann hast du ja bald auch selbst Verwendung für den Push-Server. Wie
> willst du die SDM630 auslesen? In der c't gabs vor kurzem einen größeren
> Artikel dazu, dort wurde gosdm630 (siehe Github) verwendet.
>

Das ist der Plan. Auslesen schaue ich gerate gitaeuber an, ich suche etwas
das auch funktioniert wenn die MW weg ist. Mit den aktuellen Patches werde
ich aber erstmal vzlogger den Vorzug geben.

Du weißt dass die Import-/Export-Zählwerke beim SDM630 nicht
> phasensaldierend arbeiten?
>

Nein? Muss mich das bei virtuellen Kanälen aber interessieren?


> PS bzgl. 'next' Features: Ich bastele gerade an einem Feature das es
> erlauben würde eigene, komplexere Funktionen auf Basis der Middleware zu
> implementieren. Konkret denke ich dabei z.B. an einen Batteriespeicher der
> sich damit aufgrund des bekannten Istprofils (Einspeisung + Netzbezug)
> simulieren und visualisieren ließe. Geht natürlich auch alles in Excel aber
> mit Visualisierung der Lastgänge mit und ohne Speicher fand ich einfach
> spannender.
>
>
> Sehr geil! Kann man da schon was testen? Läuft das dann auf den
> vollständigen (nicht aggregierten) Daten?
>

Nein + Ja. Ich brauche erst
https://github.com/volkszaehler/volkszaehler.org/pull/626 als vernünftige
Basis für eine Integration- es gibt zuviel gewachsenen Code der aufgeräumt
werden muss.

Bin gerade dabei Komponenten für ein kleines Selbstbau-Speicher-Experiment
> zusammenzusuchen. Eine Simulation
> für verschiedene Leistungen des Batteriewechselrichters könnte ich gut
> brauchen.
>

Mein Speichermodell ist ziemlich simpel: Kapazität, min/max Entladng/Ladung
und Effizienz. Also Ausgänge gibt es Lade- und Entladeleistung womit sich
die Eingangskanäle (Bezug und Lieferung) wieder korrigieren lassen. Im
Ergebnis können alle Batterieparameter also auch die Ein- Ausgangskanäle
geplottet werden.

Wenns fertig ist poste ich im PV Forum dazu.


> Grüße
> Frank
>
> vg
Andreas


> Am 11.09.2017 11:51 schrieb "Udo1" :
>>
>>> Hallo Frank,
>>>
>>> Am 11.09.2017 um 11:21 schrieb Frank Richter:
>>>
 Grundsätzlich sollte ich mir sowieso eine andere Distribution suchen

>>>
>>> ich benutze DietPi, http://dietpi.com/
>>>
>>> Gruß
>>> Udo
>>>
>>
>
>
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Daniel Lauckner]

Hallo,


am Dienstag, 12. September 2017 um 12:32 hat Udo1 geschrieben:
> Die Abhängigkeiten, wie im Wiki beschrieben, müssen natürlich vorher
> installiert werden. Dazu sollte man tunlichst vorher ein apt-get update
> machen.

Vzlogger zu kompilieren hatte ich auch nie Probleme wenn die
Voraussetzungen entsprechend aufgedröselt waren. Ein oder 2 hab ich ja
selbst im Wiki dokumentiert.
Aber die fertigen Binaries waren nie austauschbar.


mfg Daniel

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Udo1]

Am 12.09.2017 um 11:33 schrieb Daniel Lauckner:

Vzlogger, in der Standard-Compiler Konfiguration, kann daher nicht
zwischen Bananian, Raspian "Jessie" oder Raspian "Woody" getauscht
werden.
Da habe ich bei der manuellen Installation von vzlogger noch nie 
Probleme gehabt, auch nicht mit DietPi.
Die Abhängigkeiten, wie im Wiki beschrieben, müssen natürlich vorher 
installiert werden. Dazu sollte man tunlichst vorher ein apt-get update 
machen.


PHP5.6 oder sogar 7 ist allerdings etwas schwieriger.Aber das betrifft 
ja nicht vzlogger.


Gruß
Udo

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Daniel Lauckner]

Hallo,


am Montag, 11. September 2017 um 09:43 hat Andreas Goetz geschrieben:
> Falls die Raspian Binaries prinzipiell auf dem Banana laufen (ist
> ja alles die gleiche ARM Architktur?) dann sollte das gehen.

Tun sie nicht.
Das Problem ist meines Wissens allerdings nicht die Architektur
sondern das Libraries gerne verlinkt werden. Bringt das BS dann andere
Libs mit oder versteckt die an anderer Stelle ist das Bin schon nicht
mehr lauffähig.

Vzlogger, in der Standard-Compiler Konfiguration, kann daher nicht
zwischen Bananian, Raspian "Jessie" oder Raspian "Woody" getauscht
werden.


mfg Daniel

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Frank Richter]

Hi Andreas,

Am 11.09.2017 13:31 schrieb "Andreas Goetz" :

Servus,

2017-09-11 12:36 GMT+02:00 Frank Richter :

> Hallo Udo,
>
> jepp, DietPi ist momentan mein Favorit. Das derzeit verfügbare Image für
> den Banana Pro ist allerdings auch noch jessie, kein stretch. Damit gibt es
> PHP 7 wohl auch nur mit Handarbeit.
>

Ist aber auch kein Hexenwerk ;)


ich geb mir Mühe ;-)


Was ich am Raspi3 bzw. an Raspbian mag ist die Fähigkeit zum Netboot.
Prinzipiell sollte das ja mit DietPi auch möglich sein wenn der (boot
kernel?) alles Notwendige mitbringt- ich konnte aber nicht rausfinden ob
das tatsächlich jemandem gelungen ist (http://dietpi.com/phpbb/viewt
opic.php?f=12=1293).


Der Banana Pro hat ja SATA on board, daran habe ich ne kleine SSD und
seitdem keinen Ärger mehr mit Speicherkarten. Deshalb hab ich mich an
Netboot noch nicht versucht. Das wär was für meine 3 Pi in den
Zählerkästen, auf denen nur vzlogger läuft. Aber die sind leider alle aus
der 1. Raspi-Generation, und Netboot geht soweit ich weiß nur beim Pi 3.


Für den Raspi3 hab ich mittlerweile so meine Erfahrungen was beim Netboot
geht oder auch nicht und er startet jetzt 100% remote ohne SD Karte. Damit
ist das Kerlchen perfekt vorbereitet um in naher Zukunft in den
Zählerschrank einzuziehen und da die beiden SDM630 zu bespassen :)


Cool, dann hast du ja bald auch selbst Verwendung für den Push-Server. Wie
willst du die SDM630 auslesen? In der c't gabs vor kurzem einen größeren
Artikel dazu, dort wurde gosdm630 (siehe Github) verwendet.
Du weißt dass die Import-/Export-Zählwerke beim SDM630 nicht
phasensaldierend arbeiten?

PS bzgl. 'next' Features: Ich bastele gerade an einem Feature das es
erlauben würde eigene, komplexere Funktionen auf Basis der Middleware zu
implementieren. Konkret denke ich dabei z.B. an einen Batteriespeicher der
sich damit aufgrund des bekannten Istprofils (Einspeisung + Netzbezug)
simulieren und visualisieren ließe. Geht natürlich auch alles in Excel aber
mit Visualisierung der Lastgänge mit und ohne Speicher fand ich einfach
spannender.


Sehr geil! Kann man da schon was testen? Läuft das dann auf den
vollständigen (nicht aggregierten) Daten?
Bin gerade dabei Komponenten für ein kleines Selbstbau-Speicher-Experiment
zusammenzusuchen. Eine Simulation
für verschiedene Leistungen des Batteriewechselrichters könnte ich gut
brauchen.

Grüße
Frank


Am 11.09.2017 11:51 schrieb "Udo1" :
>
>> Hallo Frank,
>>
>> Am 11.09.2017 um 11:21 schrieb Frank Richter:
>>
>>> Grundsätzlich sollte ich mir sowieso eine andere Distribution suchen
>>>
>>
>> ich benutze DietPi, http://dietpi.com/
>>
>> Gruß
>> Udo
>>
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Andreas Goetz]

Servus,

2017-09-11 12:36 GMT+02:00 Frank Richter :

> Hallo Udo,
>
> jepp, DietPi ist momentan mein Favorit. Das derzeit verfügbare Image für
> den Banana Pro ist allerdings auch noch jessie, kein stretch. Damit gibt es
> PHP 7 wohl auch nur mit Handarbeit.
>

Ist aber auch kein Hexenwerk ;)

Was ich am Raspi3 bzw. an Raspbian mag ist die Fähigkeit zum Netboot.
Prinzipiell sollte das ja mit DietPi auch möglich sein wenn der (boot
kernel?) alles Notwendige mitbringt- ich konnte aber nicht rausfinden ob
das tatsächlich jemandem gelungen ist (
http://dietpi.com/phpbb/viewtopic.php?f=12=1293).

Für den Raspi3 hab ich mittlerweile so meine Erfahrungen was beim Netboot
geht oder auch nicht und er startet jetzt 100% remote ohne SD Karte. Damit
ist das Kerlchen perfekt vorbereitet um in naher Zukunft in den
Zählerschrank einzuziehen und da die beiden SDM630 zu bespassen :)


> Grüße
> Frank
>
>
Viele Grüße,
Andreas

PS bzgl. 'next' Features: Ich bastele gerade an einem Feature das es
erlauben würde eigene, komplexere Funktionen auf Basis der Middleware zu
implementieren. Konkret denke ich dabei z.B. an einen Batteriespeicher der
sich damit aufgrund des bekannten Istprofils (Einspeisung + Netzbezug)
simulieren und visualisieren ließe. Geht natürlich auch alles in Excel aber
mit Visualisierung der Lastgänge mit und ohne Speicher fand ich einfach
spannender.

Am 11.09.2017 11:51 schrieb "Udo1" :
>
>> Hallo Frank,
>>
>> Am 11.09.2017 um 11:21 schrieb Frank Richter:
>>
>>> Grundsätzlich sollte ich mir sowieso eine andere Distribution suchen
>>>
>>
>> ich benutze DietPi, http://dietpi.com/
>>
>> Gruß
>> Udo
>>
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Frank Richter]

Hallo Udo,

jepp, DietPi ist momentan mein Favorit. Das derzeit verfügbare Image für
den Banana Pro ist allerdings auch noch jessie, kein stretch. Damit gibt es
PHP 7 wohl auch nur mit Handarbeit.

Grüße
Frank

Am 11.09.2017 11:51 schrieb "Udo1" :

> Hallo Frank,
>
> Am 11.09.2017 um 11:21 schrieb Frank Richter:
>
>> Grundsätzlich sollte ich mir sowieso eine andere Distribution suchen
>>
>
> ich benutze DietPi, http://dietpi.com/
>
> Gruß
> Udo
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Udo1]

Hallo Frank,

Am 11.09.2017 um 11:21 schrieb Frank Richter:

Grundsätzlich sollte ich mir sowieso eine andere Distribution suchen


ich benutze DietPi, http://dietpi.com/

Gruß
Udo

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Frank Richter]

Hi Andreas,

danke für die Tipps, muss ich mal testen.

Grundsätzlich sollte ich mir sowieso eine andere Distribution suchen, weil
das aktuell laufende Bananian nicht weiterentwickelt wird. Ich schieb die
Neueinrichtung allerdings bisher vor mir her, weil es bestimmt ewig dauert
bis das alles wieder so läuft wie gewohnt... Außerdem stecken wir grad in
der Weinlese, da bleibt wenig Zeit für Basteleien.

Grüße
Frank

Am 11.09.2017 09:44 schrieb "Andreas Goetz" :

> Hi Frank,
>
> mit dem Banana kenne ich mich nicht aus. Prinzipiell könntest man aber
> auch die stretch Quellen hinzuführen und von dort installieren:
>
> apt install -t stretch php7
>
> Dazu in /etc/apt/preferences sicherstellen dass stretch dort mit priority
> 10 (statt 500 für jessie) auftaucht.
>
> Falls die Raspian Binaries prinzipiell auf dem Banana laufen (ist ja alles
> die gleiche ARM Architktur?) dann sollte das gehen. Dich würde ich
> jedenfalls sehr ungern als Cheftester verlieren ;)
>
> Viele Grüße,
> Andreas
>
> 2017-09-10 12:42 GMT+02:00 Frank Richter :
>
>> Hi Andreas,
>>
>> wenn es für die Entwicklung Vorteile bringt und auf dem RPi ohne
>> Klimmzüge läuft, machen!
>> Ich müsste dann nur mal schauen, ob ich meinem Banana Pro (jessie) auch
>> PHP 7 beibringen kann. Mit stretch ist da leider nicht zu rechnen.
>>
>> Grüße
>> Frank
>>
>> Am 09.09.2017 12:22 schrieb "Andreas Goetz" :
>>
>>> Hallo Zusammen,
>>>
>>> seit einiger Zeit war es möglich PHP7 auf Debian/Raspbian jessie zu
>>> installieren. Seit auch Raspian bei stretch angekommen ist ist PHP7
>>> standardmäßig verfügbar. Die Programmierung mittels PHP7 ist an vielen
>>> Stellen angenehmer als mit 5.6.
>>>
>>> Was haltet ihr davon den aktuellen Stand der Repositories als Version zu
>>> releasen (kein Changelog, da ist so viel passiert) und dann composer
>>> und travis auf PHP7 umzustellen? Ab diesem Zeitpunkt wird keine
>>> Installation auf 5.6 mehr möglich sein.
>>>
>>> Wie seht ihr das?
>>>
>>> Viele Grüße, Andreas
>>>
>>>
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Frank Richter]

Hi Andreas,

wenn es für die Entwicklung Vorteile bringt und auf dem RPi ohne Klimmzüge
läuft, machen!
Ich müsste dann nur mal schauen, ob ich meinem Banana Pro (jessie) auch PHP
7 beibringen kann. Mit stretch ist da leider nicht zu rechnen.

Grüße
Frank

Am 09.09.2017 12:22 schrieb "Andreas Goetz" :

> Hallo Zusammen,
>
> seit einiger Zeit war es möglich PHP7 auf Debian/Raspbian jessie zu
> installieren. Seit auch Raspian bei stretch angekommen ist ist PHP7
> standardmäßig verfügbar. Die Programmierung mittels PHP7 ist an vielen
> Stellen angenehmer als mit 5.6.
>
> Was haltet ihr davon den aktuellen Stand der Repositories als Version zu
> releasen (kein Changelog, da ist so viel passiert) und dann composer
> und travis auf PHP7 umzustellen? Ab diesem Zeitpunkt wird keine
> Installation auf 5.6 mehr möglich sein.
>
> Wie seht ihr das?
>
> Viele Grüße, Andreas
>
>

Re: [vz-dev] Unterstützung für PHP 5.6 entfernen?

[Justin Otherguy]

Moin,

habe vorhin mal g’schwind(tm) demo.volkszaehler.org von jessie auf stretch 
angehoben; war ziemlich schmerzfrei (phpmyadmin hat um Neuinstallation gebeten).

Aus meiner Sicht läuft nun alles wieder rund - ich bitte um Hinweise, falls 
Euch Fehler in der Matrix auffallen.


Gruß, J.

> Am 09.09.2017 um 12:21 schrieb Andreas Goetz :
> 
> Hallo Zusammen,
> 
> seit einiger Zeit war es möglich PHP7 auf Debian/Raspbian jessie zu 
> installieren. Seit auch Raspian bei stretch angekommen ist ist PHP7 
> standardmäßig verfügbar. Die Programmierung mittels PHP7 ist an vielen 
> Stellen angenehmer als mit 5.6.
> 
> Was haltet ihr davon den aktuellen Stand der Repositories als Version zu 
> releasen (kein Changelog, da ist so viel passiert) und dann composer und 
> travis auf PHP7 umzustellen? Ab diesem Zeitpunkt wird keine Installation auf 
> 5.6 mehr möglich sein.
> 
> Wie seht ihr das?
> 
> Viele Grüße, Andreas

[vz-dev] Unterstützung für PHP 5.6 entfernen?

[Andreas Goetz]

Hallo Zusammen,

seit einiger Zeit war es möglich PHP7 auf Debian/Raspbian jessie zu 
installieren. Seit auch Raspian bei stretch angekommen ist ist PHP7 
standardmäßig verfügbar. Die Programmierung mittels PHP7 ist an vielen Stellen 
angenehmer als mit 5.6.

Was haltet ihr davon den aktuellen Stand der Repositories als Version zu 
releasen (kein Changelog, da ist so viel passiert) und dann composer und 
travis auf PHP7 umzustellen? Ab diesem Zeitpunkt wird keine Installation auf 
5.6 mehr möglich sein.

Wie seht ihr das?

Viele Grüße, Andreas