[Gelöst]update wird nicht sauber beendet

Begonnen von chanky, 29 November 2020, 11:23:13

Vorheriges Thema - Nächstes Thema

chanky

@Rudi, Mit dem Workaround funktioniert
@Betateilchen welche andere Dinge hast du gemeint?
Ich kennen nur diesen:

set LigistHeater off : Please define LigistHeater first
PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE .TempSens.*$/ at ./FHEM/33_readingsGroup.pm line 154


1: Da das Problem hier ist das meine Funktion aufgerufen wird, bevor die Initialisierung fertig ist,  Das Device existiert schon, ich muss nur noch ein Delay einbauen.
2: Tut nicht weh, da muss ich mein regex Ausdrück fein tunen.

Was sollte noch ausgebessert werden?

LG

betateilchen

Na immerhin hast Du ja ein paar Mängel schon selbst erkannt.

Zitat von: chanky am 30 November 2020, 19:41:08

set LigistHeater off : Please define LigistHeater first

1: Da das Problem hier ist das meine Funktion aufgerufen wird, bevor die Initialisierung fertig ist,  Das Device existiert schon, ich muss nur noch ein Delay einbauen.

Wo wird denn der set Befehl ausgeführt? Und warum so früh?

Zitat von: chanky am 30 November 2020, 19:41:08

PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE .TempSens.*$/ at ./FHEM/33_readingsGroup.pm line 154

2: Tut nicht weh, da muss ich mein regex Ausdrück fein tunen.

Nein, weh tut das nicht, aber aus Performancegründen sollte man sowas grundsätzlich beseitigen.



Zitat von: chanky am 30 November 2020, 19:41:08

2020.11.30 17:36:59 1: PERL WARNING: Subroutine getStateText redefined at ./FHEM/99_myUtils.pm line 434.


Das deutet darauf hin, dass entweder die 99_myUtils.pm zweimal geladen wird, oder dass eine bereits vorhandene Funktion getStateText() in Deiner 99_myUtils.pm unter gleichem Namen nochmal vorhanden ist und damit die erste Funktion überschreibt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Ich tippe auf die MASQUERADE Zeile, aber ich bin kein iptables Experte, und will meinen Rechner auch nicht zum Test verkonfigurieren. Sonst habe ich keine Idee.
Wenn jemand die Ursache erklaeren kann: ich bin neugierig.

chanky

Zitat von: betateilchen am 30 November 2020, 19:52:34
Na immerhin hast Du ja ein paar Mängel schon selbst erkannt.

Wo wird denn der set Befehl ausgeführt? Und warum so früh?

Nein, weh tut das nicht, aber aus Performancegründen sollte man sowas grundsätzlich beseitigen.



Das deutet darauf hin, dass entweder die 99_myUtils.pm zweimal geladen wird, oder dass eine bereits vorhandene Funktion getStateText() in Deiner 99_myUtils.pm unter gleichem Namen nochmal vorhanden ist und damit die erste Funktion überschreibt.

mein set Befehl wird hier ausgeführt:

sub LigistUtils_Initialize($$)
{
    my ($hash) = @_;
    fhem("set LigistHeater off");
}


1:Ich wollte ein Failsafe Funktion simulieren dass wenn mein RPi neue gestartet wird zB. durch ein Reset  dass die Heizung immer von off startet (neustart neues spiel).
Ich werde das mit dem "at" + offset command austauschen außer du hast noch etwas eleganter  :P

2:Regex habe ich von *.TempSens.* auf ^[a-zA-Z]+TempSens.*

3:Das zwei mal laden kommt nur wenn Änderungen in 99_myUtils.pm gespeichert werden.

zum IP  routing Debian hat was umgestellt, ich werde da einlesen  ich kenne mich zu wenig aus und danach  werde ich probieren meine Ip Tables aufzuräumen.
https://unix.stackexchange.com/questions/584637/iptables-legacy-with-normal-iptables-in-debian-buster

Vielen Dank euch alle für eure Hilfe mit dem "Update" work around bin ich zu frieden. Ich werde dann das Thread als gelöst markieren

LG
Chanky




MadMax-FHEM

Eleganter für Ausführung bei fhem-Start:


define nStartup notify global:INITIALIZED set LigistHeater off


Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

chanky

Zitat von: rudolfkoenig am 30 November 2020, 20:27:28
Ich tippe auf die MASQUERADE Zeile, aber ich bin kein iptables Experte, und will meinen Rechner auch nicht zum Test verkonfigurieren. Sonst habe ich keine Idee.
Wenn jemand die Ursache erklaeren kann: ich bin neugierig.


pi@Home-Server:~ $ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
   16   960 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 to:192.168.253.2:80
    0     0 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:1999 to:192.168.253.2:1999
    0     0 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2000 to:192.168.253.2:2000
    0     0 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2001 to:192.168.253.2:2001
    0     0 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2002 to:192.168.253.2:2002
    0     0 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2010 to:192.168.253.2:2010
    0     0 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8181 to:192.168.253.2:8181
    0     0 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8183 to:192.168.253.2:8183
    0     0 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8700 to:192.168.253.2:8700
    0     0 DNAT       tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8701 to:192.168.253.2:8701

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
   43  2884 MASQUERADE  all  --  *      *       192.168.253.0/24     0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         


Super Tipp! Ich hab jetzt mein WLAN bridge neu eingerichtet (die Zeile mit MASQUERADE schaut auch besser jetzt )und aufgeräumt und das Update geht jetzt wieder ganz normal. Schuld war piVCCU3 update hat das Tool mein Routing Table hin gemacht, böses Tool!