DOIF u. at

[satprofi]

Hallo.
Wie kann ich verhindern das ein DOIF u. at sich nicht stören?
Habe den Verdacht, das ein at, das alle 2 Minuten meinen WR abfrägt, und ein DOIF das den WR bei bestimmten Ereignissen regelt,sich manchmal überschneiden und komische Werte ankommen.
Beide starten ein Python Script. Kann man ein periodisches at in ein DOIF integrieren?

[Per]

Wenn du den Code mitgepostet hättest, könnte man schon schauen.
Prinzipiell können DOIF und at zusammenarbeiten, meist ist at aber nicht mehr notwendig.

[satprofi]

Wenn du den Code mitgepostet hättest, könnte man schon schauen.
Prinzipiell können DOIF und at zusammenarbeiten, meist ist at aber nicht mehr notwendig.

Das at startet alle 2min. ein Script,

Code Auswählen Erweitern

+*00:02:00 "python2 /usr/local/bin/Xtender.py"
das DOIF je nach Ereignis (Stromüberschuss, Strompreis) ein weiteres Script.

Code Auswählen Erweitern

([Ladestrom:state] eq "2" and [Ausgleichsladung] eq "off" and (($month >2 and $month <9 and [PylonTech_mSOC] >[SOC_soll])
 or (($month <3 or $month >9) and [PylonTech_mSOC] > [SOC_soll])
 or ($month ==9 and [PylonTech_mSOC] > [SOC_soll])
 or ([20:00-07:00] and [FS20_701003] eq "off" and [Stromausfall] eq "off" and [laden_billig] eq "off"))) ("python2 /usr/local/bin/SOC_off.py", setreading Wert_I A 0, set Lader off)
DOELSEIF ([Ausgleichsladung] eq "off" and [PylonTech_mSOC] <90 and [SOC_max_min:maxCurrent] >89 and (([FS20_701003] eq "on"
 or ([PylonTech_mSOC] <[SOC_soll] and (([laden_billig] eq "on" and ([Open_Meteo:1] <27000 or [PylonTech_mSOC] <50)) or ([Strompreis_heute:now] < [min2:state])) and [Lader] eq "on")
 or ([Stromausfall] eq "on" and [Ladestrom:state] eq "2")
 or ([Ladestrom:state] eq "80" and [Ueberschuss] >650)
 or ([Ladestrom:state] eq "82" and [Ueberschuss] >520)
 or ([Ladestrom:state] eq "84" and [Ueberschuss] >390)
 or ([Ladestrom:state] eq "86" and [Ueberschuss] >260)
 or ([Ladestrom:state] eq "88" and [Ueberschuss] >130)))) ("python2 /usr/local/bin/92Amp.py")

Die Scripte öffnen einen rs232 Port.

Code Auswählen Erweitern


#!/usr/bin/python
import serial
import struct
# configure the serial connections (the parameters differs on the device you are connecting to)
port = serial.Serial(
    port='/dev/ttyRS232',
    baudrate=38400,
    parity=serial.PARITY_EVEN,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS,
    timeout=2,
    xonxoff=False,
    rtscts=False,
    dsrdtr=False
)
cmd92Amp = '\xAA\x00\x01\x00\x00\x00\x65\x00\x00\x00\x0E\x00\x73\x79\x00\x02\x02\x00\x72\x04\x00\x00\x05\x00\x00\x00\x30\x42\xF0\x7C' # Ladestrom
# commandos senden
port.write(cmd92Amp)
port.close()
Und für Auslesen des Status das Script von at, selber Aufbau.
Habe überlegt das ganze in die 99_myutils.pm zu packen, aber da steh ich leicht an.

[Per]

Da das DOIF keinen eigenen Timer hat und nur auf die Ergebnisse des von at gestarteten Scriptes reagiert, sehe ich auf dem ersten Blick keine Probleme. Dass sich die Scripte selbst nicht ins Gehege kommen, davon gehe ich mal aus.
Selftriggerung wird zwar verhindert, wird aber umgangen, wenn das Script zwischenges chaltet ist.
Was sagt denn das Eventlog?

Was mir aber nebenbei auffällt, sind die Unmengen or, bei denen ich von einem historischen Wachstum ausgehe.

Code Auswählen Erweitern

or (($month <3 or $month >9) and [PylonTech_mSOC] > [SOC_soll])
 or ($month ==9 and [PylonTech_mSOC] > [SOC_soll])ist gleich

Code Auswählen Erweitern

or (($month <3 or $month >= 9) and [PylonTech_mSOC] > [SOC_soll])oder

Code Auswählen Erweitern

or (($month < 3 or $month > 10) and [PylonTech_mSOC] > [SOC_soll])Und den März hast du übersprungen.

Statt

Code Auswählen Erweitern

or ([Ladestrom:state] eq "80" and [Ueberschuss] >650)
 or ([Ladestrom:state] eq "82" and [Ueberschuss] >520)
 or ([Ladestrom:state] eq "84" and [Ueberschuss] >390)
 or ([Ladestrom:state] eq "86" and [Ueberschuss] >260)...Kannst du auch

Code Auswählen Erweitern

[Ueberschuss] > ((90 - [Ladestrom:state]) * 130)nehmen.

[satprofi]

Danke für die Infos. Ja, über die Jahre gewachsen. Ladestromsteuerung meines Akkus, von Fixpreis zu Spotpreis, usw.

Werde mal aufräumen. Was mir noch einfällt, DOIF kann doch auch periodisch Kommandos senden, oder? Wenn ich das alle 2min. hier einbauen als zusätzliches DOELSE ?

Bzgl. in die Quere kommen, das genau befürchtete ich aber. Denn wenn das "at" ausgeführt wird, kann ja zeitgleich DOIF senden. Und so kommen die komischen Werte zusammen.

[Per]

Wenn DOIF und at ans selbe Device senden, kann es natürlich komisch werden, aber eigentlich sollte das DOIF doch nur auf die Ausgaben vom Script reagieren (triggern) und nicht selbst tätig werden.
Evtl müsstest du manche Abfragen mit Fragezeichen maskieren, damit sie nicht triggern.

[satprofi]

Das at ermittelt alle 2min. den SOC u. WR-Status. Das DOIF wird vom Smartmeter alle 20sec. getriggert, je nach Überschuss oder Bezug. Natürlich mit wait von 30sec. , um evtl. Einbrüche durch Wolken oder Sonneneinstrahlung zu kompensieren.
Das ließe sich sicher mit Script in myUtils lösen, wenn der Überschuss um 130W zunimmt dann erhöhe Ladestrom um 2A , und wenn Bezug stattfindet verringere um 10A bis zu Ladestopp. Aber dafür bin ich zu wenig Programmierer, deshalb hab ich das per DOIF gelöst.

[MadMax-FHEM]

Aber wenn die Scripte über USB bzw. RS232 also serielle Schnittstelle kommunizieten, dann kann da doch nichts durcheinander kommen?

Maximal bekommt ein Script einen Fehler, weil die Schnittstelle gerade vom anderen Script genutzt wird.

Es sind doch 2 Scripte die ähnliches tun?
Zumindest hab ich das so gelesen...

Gruß, Joachim

[satprofi]

Maximal bekommt ein Script einen Fehler, weil die Schnittstelle gerade vom anderen Script genutzt wird.

Es sind doch 2 Scripte die ähnliches tun?
Zumindest hab ich das so gelesen...

Gruß, Joachim

Richtig, und diese Fehler wollte ich vermeiden. Ist nicht oft, aber immerhin

[Per]

Du kannst das DOIF kurzzeitig disablen oder den Status des Scriptes (running) mit in die Abfrage aufnehmen.

[Per]

Noch eine Anmerkung von mir:
Statt mit at ein Dummy zu füllen würde ich mit DOIF ein "echtes" Device erstellen, bei dem alle Werte zusammenlaufen.
Das kannst du dann auch loggen, triggern und grafisch aufbereitet bei Bedarf.
Einige der von mir damals (TM) als .pm erstellten Devices würde ich heute als Perl DOIF machen.