Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

noansi

Hallo yersinia,

erst mal Bordmittel.

Hast Du mal versucht, das Attribut 'forceAlivePing' auf 1 zu setzen?

Dann wird alle 59 Sekunden ein spezielles "ping" an den nano gesendet und wenn er nicht antwortet, wird die Verbindung getrennt und sie sollte neu aufgebaut werden. Eigentlich für Netzwerk HM IOs gedacht, aber auch bei anderer Verbindungsart nutzbar.

Richtig wäre natürlich, das Übel bei der Wurzel zu packen und den buggy Unterbau zu reparieren, in dem Fall auf den älteren funktionierenden Stand.

Gruß, Ansgar.

yersinia

Zitat von: noansi am 11 November 2022, 19:56:25Hast Du mal versucht, das Attribut 'forceAlivePing' auf 1 zu setzen?
Neee, das war mir gar nicht bekannt. Aber guter Hinweis, ich setz' es mal und beobachte.
Erstaunlicherweise habe ich mit dem via Netzwerk angebundenen nanoCUL keinerlei Probleme. Aber da schadet das Attribut forceAlivePing ja auch nicht.

ZitatRichtig wäre natürlich, das Übel bei der Wurzel zu packen und den buggy Unterbau zu reparieren, in dem Fall auf den älteren funktionierenden Stand.
Ja, ich werde es beobachten. Weil sonst läuft alles - und andere RasPis (gleiches OS, gleicher Kernel mit USB Geräten) haben keine Probleme (derzeit).
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

exocet01

#1367
Zitat von: noansi am 24 September 2022, 21:57:54
Hallo Eckart,

im Anhang eine neue Testfirmware. Ich habe ihr eine VTS 0.40 verpasst, obwohl sie eigentlich eine VTS 0.41 ist, damit Du mit den älteren FHEM Modulen Somfy testen kannst. Also bitte auch nur dafür verwenden und nicht etwa für Deinen 868er.

Ich bin diesmal optimistischer, dass es besser klappt. Die Manchesterumsetzung hatte ihre Tücken.

Nebenbei habe ich noch bemerkt, dass sowohl in der Standard culfw, als auch in der a-culfw die frame-Pause zwischen den Wiederholungen viel zu kurz ausfällt, wegen fehlender Klammern in der betreffenden Sourcecode Zeile.
my_delay_us(30415 + ((frame[6] >> 7) & 1) ? 0 : somfy_rts_interval_half);
Macht nicht in somfy_rts.c das von
my_delay_us(30415 + (((frame[6] >> 7) & 1) ? 0 : somfy_rts_interval_half));
erwartete (falls Rudolf und Björn hier mal rein schauen).
Scheint, Deine Rollos aber anscheinend wenig zu stören.

Gruß, Ansgar.

Hallo Ansgar,

seit kurzem funktioniert die Steuerung der Somfy Rollos nicht mehr. Sie sind langsam nacheinander ausgefallen. Jetzt funktionieren nurn noch 2. Ich habe keine Änderungen vorgenommen und auch an dem CUL nichts geändert. Die IT V1 Steckdose funktioniert noch einwandfrei (Nur die IT V3 funktioniert nicht richtig). Kann es sein dass es an dem Code oben liegt? Der Handsender funktioniert noch immer einwandfrei und die Rolling codes können es eigentlich auch nicht sein, weil ich diese immer automatisch Backuppe (Also im Falle eines Stromausfalls....hatte ich mal)

Gruß
Eckart

noansi

Hallo Eckart,

Zitatseit kurzem funktioniert die Steuerung der Somfy Rollos nicht mehr. Sie sind langsam nacheinander ausgefallen.
Gegenfrage: Wie lange hat es problemlos funktioniert?
Denn Du hast lange keine weitere Rückmeldung gegeben.

ZitatKann es sein dass es an dem Code oben liegt?
Glaube ich nicht. Sonst hättest Du Dich schon früher gemeldet.

ZitatIch habe keine Änderungen vorgenommen und auch an dem CUL nichts geändert.
Vielleicht irgendwas in den Funkweg gestellt?
Was sagt ein get PAtable1 beim CUL?
Sendet irgendwas häufig gleichzeitig auf der gleichen Frequenz (433.42)? Z.B. ein Funkthermometer?

Gruß, Ansgar.


noansi

Hallo Eckart,

ZitatDer Handsender funktioniert noch immer einwandfrei und die Rolling codes können es eigentlich auch nicht sein
Benutzt Du den Handsender immer mal wieder zur Steuerung der Rollos?
Der Handsender zählt seinen eigenen Rolling Code.

CUL empfängt keine SOMFY Telegramme -> synchronisiert FHEM damit nicht auf den Handsender Rolling Code. Was Du vom CUL als Ys siehst, sind nur die Rückmeldungen gesendeter Telegramme.

Wenn FHEM und Handsender damit weit genug auseinander laufen, bricht die reguläre Steuerung via FHEM (oder Handsender?) zusammen, weil das Rollo einen anderen gültigen Rolling Code Bereich erwartet.
-> Steuerung der Rollos nur über FHEM und nicht über Handsender, wenn es via FHEM funktionieren soll

Gruß, Ansgar.

exocet01

Hallo Ansgar,

nachdem auch die IT Dose nicht mehr funktionierte und ich somit einen HW Defekt vermutete, habe ich einen neuen CUL gekauft.
Jetzt funktioniert es wieder.

Vielen Dank und frohe Weihnachten!!!!
Eckart

Adimarantis

Hi Ansgar,

ich bekomme im Logfile nahezu im Sekundenabstand folgendes:
2023.02.26 22:57:56.997 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4766.
2023.02.26 22:57:57.007 1: stacktrace:
2023.02.26 22:57:57.012 1:     main::__ANON__                      called by fhem.pl (4766)
2023.02.26 22:57:57.015 1:     main::AttrVal                       called by ./FHEM/00_TSCUL.pm (1382)
2023.02.26 22:57:57.019 1:     main::TSCUL_ParseTsHM               called by ./FHEM/00_TSCUL.pm (707)
2023.02.26 22:57:57.023 1:     main::TSCUL_Parse                   called by ./FHEM/00_TSCUL.pm (643)
2023.02.26 22:57:57.026 1:     main::TSCUL_Read                    called by fhem.pl (3976)
2023.02.26 22:57:57.030 1:     main::CallFn                        called by fhem.pl (784)

Scheint was mit Repeatern zu tun zu haben? Sowas habe ich tatsächlich im Haus, aber nicht über die CUL konfiguriert.

Desweiteren verzweifele ich gerade ein weiteres HM-CC-VD Ventil einzubinden. Sieht so als könnte ich zwar vom Ventil empfangen, wodurch ein Pairing erstmal möglich ist. Aber meine Befehle werden nicht empfangen/bearbeitet. Das einzig seltsame ist, dass die peerList mit einem FHEM unbekannten Gerät belegt ist - kann das ein Überbleibsel sein, dass nun stört?
Sonst habe ich schon mit dem Frequenzoffset gespielt - aber da erreiche ich nur, dass irgendwann meine beiden anderen Ventile auch nicht mehr funktionieren.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

noansi

Hallo Jörg,

ZitatPERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4766.
Das ist (meiner Meinung nach) eine Schwäche in AttrVal($$$) in fhem.pl, da ein undefinierter Name mit übergeben wird, in der Funktion nicht überprüft wird, ob er nicht definiert ist und dann damit auf hashes zugeriffen wird, statt nur den ebenfalls übergebenen Default Wert zurück zu liefern.

Das der Name undefiniert ist, liegt vermutlich an einem noch nicht oder nicht richtig angelernten device, was einen kaputten device hash erzeugt hat.

ZitatDesweiteren verzweifele ich gerade ein weiteres HM-CC-VD Ventil einzubinden.
Passt also zu Deinem weiteren Problem mit dem Ventil.

Ist das HM-CC-VD Ventil noch an einer anderen Zentrale angemeldet, sprich, nicht abgemeldet oder nicht auf Werkseinstellungen zurück gesetzt?
Dann würde es die Zusammenarbeit verweigern.
Wenn das Ventil kaputt sein sollte, kann es eventuell nicht empfangen aber noch senden.

Ein raw logging, mit verbose 4 beim CUL, eines Pairing Versuchs zeigt vielleicht Hinweise.
Weiterhin ein list des Deiner Meinung nach gepairten Ventils.

Gruß, Ansgar.

Adimarantis

Zitat von: noansi am 27 Februar 2023, 20:16:20
Das ist (meiner Meinung nach) eine Schwäche in AttrVal($$$) in fhem.pl, da ein undefinierter Name mit übergeben wird, in der Funktion nicht überprüft wird, ob er nicht definiert ist und dann damit auf hashes zugeriffen wird, statt nur den ebenfalls übergebenen Default Wert zurück zu liefern.
Wäre trotzdem schön das irgendwie so zu handhaben, dass es keine Warning gibt. Mit der "Schwäche" müssen wir halt als Entwickler aktuell leben.

Zitat von: noansi am 27 Februar 2023, 20:16:20
Ist das HM-CC-VD Ventil noch an einer anderen Zentrale angemeldet, sprich, nicht abgemeldet oder nicht auf Werkseinstellungen zurück gesetzt?
Dann würde es die Zusammenarbeit verweigern.
Das wollte ich nochmal probieren (an "echter" CCU anmelden und Werkseinstellungen). Bisher hatte ich es nur abgemeldet. Mach ich wenn ich wieder daheim bin.
Ein HW Defekt ist denke ich mal unwahrscheinlich, da ich das selbe Problem mit zwei verschiedenen Ventilen habe.

Ich habe allerdings festgestellt, dass sich FHEM die Ventile ungefragt einverleibt (ohne das pairForSec gesetzt wurde).
Da meine CCU und HM_CUL beide die Geräte empfangen können, ist es teilweise gar nicht so einfach sie an der CCU anzumelden, da FHEM meist schneller ist.
Mache ich da was falsch, oder ist das ein Fehler in HM_CUL?

Gruß,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

noansi

Hallo Jörg,

ZitatWäre trotzdem schön das irgendwie so zu handhaben, dass es keine Warning gibt. Mit der "Schwäche" müssen wir halt als Entwickler aktuell leben.
Ich habe die Funktion abgewandelt:

sub
AttrVal($$$)
{
#  my ($d,$n,$default) = @_;
  if (defined($_[0])) {
    my $a = $attr{$_[0]};
    if (defined($a)) {
      my $n = resolveAttrRename($_[0], $_[1]);
      return $a->{$n} if(defined($a->{$n}));
    }
  }
  return $_[2];
}

Natürlich sehe ich damit einen undef übergebenen Devicenamen nicht in gezeigter Form im Log. Das Verhalten ist aber bezüglich Rückgabe das gleiche, wie in Rudolfs Original (auch Rückgabe des Defaulwertes beabsichtigt(!) geliefert). Von daher vermute ich, dass der Fall des undefinierten Namens nur nicht vollständig bezüglich Nebenwirkungen bedacht wurde.

ZitatIch habe allerdings festgestellt, dass sich FHEM die Ventile ungefragt einverleibt (ohne das pairForSec gesetzt wurde).
Welche CUL_HM verwendest Du und hast Du autocreate aktiv?

Das "einverleiben" bedeutet nicht, dass gepairt wird, sondern nur, dass ein Device auf Grund einer empfangenen Anlernmessage angelegt wird.
Bei deaktiviertem autocreate geschieht dies jedoch nicht in meinen Versionen (so der Plan), weil ich nicht Nachbars oder zufällig empfangene devices aus dem System räumen müssen möchte.

Martin hatte da mal eine andere Vorstellung zu usabilty, um bei daktiviertem autocreate dennoch pairen zu können.

Ohne pairForSec sollte CUL_HM aber kein pairing durchziehen, sprich nicht die hmid im device setzen.
Nebenwirkung des angelegten devices dürfte aber autoack des (verzögert) zugewiesenen IOs zu dem device sein. get assignIDs beim CUL würde Dir das aufzeigen.

Gruß, Ansgar.

Adimarantis

Hi Ansgar,

in fhem.pl werde ich nichts patchen. Da möchte ich ja weiter updates machen können. Habs jetzt erstmal in TSCUL auskommentiert und da ich keinen Repeater habe setze ich das Flag einfach immer fest auf 0.
Mal sehen - wahrscheinlich brauchts das nicht mehr, wenn die Config wieder konsistent ist.

Mit Werksreset, pairen, getConfig, Ventil nochmal in pairing Modus hat er es jetzt akzeptiert.
Seltsam finde ich aber schon, dass die Devices in FHEM auftauchen und auch gepaired aussehen (in PairedTo stand immer schon die korrekte ID). Da denkt man es hat alles geklappt und trotzdem geht nix. Vielleicht kann man da noch was verbessern, damit es dem Anwender klar wird, dass es nicht gehen kann.

Unmittelbares Problem auf jeden Fall erstmal gelöst.

Danke,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

noansi

Hallo Jörg,

ZitatMit Werksreset, pairen, getConfig, Ventil nochmal in pairing Modus hat er es jetzt akzeptiert.
Schön, dass es doch noch geklappt hat.

ZitatSeltsam finde ich aber schon, dass die Devices in FHEM auftauchen und auch gepaired aussehen (in PairedTo stand immer schon die korrekte ID).
??? Wieso immer schon? War es schon mal mit FHEM gepairt und existierte noch?

Ansonsten sollte es frühestens mit dem pair Versuch gesetzt werden, eventuell zu früh, also schon beim Setzversuch und nicht erst beim Rücklesen der RegL_00.

Gruß, Ansgar.

Adimarantis

Zitat von: noansi am 03 März 2023, 19:40:04
Ansonsten sollte es frühestens mit dem pair Versuch gesetzt werden, eventuell zu früh, also schon beim Setzversuch und nicht erst beim Rücklesen der RegL_00.
Das wäre was ich vermute habe. Gerade nochmal versucht das mit einem zweiten Ventil nachzustellen, aber kläglich gescheitert. Evtl. waren die Ventile bis zum Werksreset in einem seltsamen Zustand.
Habs sogar erst an der CCU angelernt, wieder abgelernt (aber ohne reset) und dann versucht am HM_CUL anzulernen - ohne Erfolg - aber auch ohne dass HM_CUL mehr als Version und Seriennummer angezeigt hätte.
Dann Werksreset und pairing erfolgreich und getConfig erfolgreich.

Eine Vermutung: Das Gerät war bei meinen Versuchen recht weit von der CUL weg. Ich hab es zwar nach dem vermeintlich erfolgreichen Pairing in die Nähe getragen, aber vielleicht ist beim Pairing selbst aufgrund der Entfernung was fehlgeschlagen, dass die ganze Sache aus dem Tritt gebracht hat.

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

noansi

Hallo Jörg,

ich habe die Module hier aktualisiert https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796

Der Stacktrace sollte an der Stelle nicht mehr auftreten.
Kannst Du das bitte nochmal testen, sprich dabei auch den ursprünglichen Stacktrace Fall nachstellen?

Gruß, Ansgar.

Adimarantis

Danke. Schaut gut aus. Hab die 0.97 wiederhergestellt und es kamen wieder die Stacktraces. Dann die 0.98 eingespielt und es war Ruhe.

Gruß,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)