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 Jörg,

ZitatKannst du damit irgendwas anfangen?
Vermutlich nicht. FM sollte es nach diesem Katalog sein:
https://www.niceforyou.com/sites/default/files/upload/catalogues-brochures/nice_era_one_de.pdf

Gruß, Ansgar.

Adimarantis

Zitat von: noansi am 02 August 2021, 22:04:27
Vermutlich nicht.

Schade. Ich muss mal sehen - alternativ kann das Teil auch Bluetooth - gibt aber nur eine iPhone App (und ich bin in der Android Fraktion). Vielleicht kann man sich ja auch da einklinken.

Btw. welche CUL würdest du eigentlich empfehlen? (meine Nano schränkt ja wohl doch etwas ein) Wenns geht mit Link zu einer Bauanleitung.

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,

den CUNX gibt es anscheinend bei Busware leider nicht mehr.

Ein interessantes Bastelprojekt könnte https://github.com/damianmelson/megaCUL-868MHz sein. Der Prozessor hat viel Flash und SRAM (der gleiche, wie bei SCC).
WLAN würde ich aber für HM gar nicht erst drauf löten, um nicht in die Versuchung des Ärgers durch gestörte Verbindung zu kommen.
Falls überhaupt noch alle Teile zu bekommen sind...
Noch schöner wäre USB nativ seitens ATMEGA Prozessor, aber dazu kenne ich bisher kein Bastelprojekt.

Hex dazu zum testen ist im gerade aktualisierten zip zu finden.

Gruß, Ansgar.

Adimarantis

Zitat von: noansi am 05 August 2021, 19:28:07
Ein interessantes Bastelprojekt könnte https://github.com/damianmelson/megaCUL-868MHz sein. Der Prozessor hat viel Flash und SRAM (der gleiche, wie bei SCC).
SMD löten übersteigt meine Fähigkeiten leider. Ich bin ja schon froh wenn ich Homematic Bausätze zusammen kriege.

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

Adimarantis

Was ganz anderes:
Ich habe zwei LEDs die über 433Mhz gesteuert werden.
Über die RFXTRX433 funktionierte das im ausgebauten Betrieb wunderbar - aber an der Zielposition ist der Empfang einfach so mies, dass es gar nicht geht.
Daher wollte ich meine 433 CUL reaktivieren, da einer meiner Raspberries ziemlich nah dran sitzt.

Mit TRX_LIGHT ist das als "PT2262" mit der Adresse "12100113" definiert. Da werden dann noch die Steuercodes, z.B. "0201" für "auf Blau schalten" angehängt.
Kann ich das mit TSCUL ansteuern? bzw. mit der aktuellen Firmware die drauf ist: "V 1.67 nanoCUL433"?

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

riker1

Hallo, hätte ne Frage.

Eventuell verstehe ich es falsch.

wenn ich set HMXXXX controlManu 22 mache,

kommt als Trigger nur

2021-10-05 08:43:31.603 CUL_HM HMxxxx controlMode: set_manual

mir fehlt dort der Temp Value also eventpart1

Oder woher bekomme ich den Temperturvalue?

Ein Event set_desired-temp sehe ich dazu nicht?

Danke für die Hilfe.

VG T

FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

noansi

Hallo riker1,

wenn Du von einem HM-CC-RT-DN schreibst, dann kommt das desired-temp event später mit der Statusmeldung vom device.

Ob das was Du Dir vorstellst sein sollte, müsstest Du im HM Bereich mit Martin diskutieren.

Gruß, Ansgar.

noansi

Hallo Jörg,

sorry, sehe ich jetzt erst.

"PT2262" kannst Du mit dem IT Modul probieren.
Wenn Du es auf anderem Wege schon senden kannst, dann bestehen auch Chancen, dass Du es mit dem 433er CUL empfangen kannst, was bezüglich Code auch der einfachste Weg zum Einrichten wäre.
Neben dem Code muss auch noch die IT Frequenz oder ITfreqOffs und der ITclock passend gewählt werden, damit Du auch richtig senden kannst. Mit Erhöhung der Repetitions kannst Du auch noch die Empfangchancen der Sendedaten erhöhen.

Edit: Senden kannst Du das mit der Standardfirmware, a-culfw und tsculfw. Für tsculfw musst Du aber das beigepackte IT Modul verwenden, für die anderen beiden das IT Modul aus dem FHEM Standard.

Gruß, Ansgar.

Adimarantis

#1283
Hi Ansgar,

danke für die Antwort. Ich war jetzt "faul" und hab mir einfach eine zweite RFXTRX433 gekauft.

Noch eine andere Frage: Mein HM-CC-VD hat neuerdings das Problem das er auf ~97% hängen bleibt (motorErr=blocked) (obwohl ich ihn eigentlich nur zwischen 0 und 25 hin und her fahre). Stromlos machen bringt das er sich wieder fängt. Kann man so einen "Reset" auch senden? Oder eine Idee warum er da überhaupt hin fährt (Entkalkungsfahrt?)

Ich hab auch mal auf deine neuste TSCUL geupdated und bekomme jetzt dauern Fehlermeldungen im Log:
2021.10.29 20:23:18.858 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4681.
2021.10.29 20:23:18.862 1: stacktrace:
2021.10.29 20:23:18.865 1:     main::__ANON__                      called by fhem.pl (4681)
2021.10.29 20:23:18.869 1:     main::AttrVal                       called by ./FHEM/00_TSCUL.pm (1382)
2021.10.29 20:23:18.873 1:     main::TSCUL_ParseTsHM               called by ./FHEM/00_TSCUL.pm (707)
2021.10.29 20:23:18.877 1:     main::TSCUL_Parse                   called by ./FHEM/00_TSCUL.pm (643)
2021.10.29 20:23:18.880 1:     main::TSCUL_Read                    called by fhem.pl (3895)
2021.10.29 20:23:18.883 1:     main::CallFn                        called by fhem.pl (773)


Irgendeine Idee?

EDIT: Ich hab mir den Fehler jetzt mal "weggepatched". Du machst ein AttrVal für ein Attribut "sndThrRep" das es nirgendwo gibt, womit m.E. immer der Defaultwert genommen wird. Also nehme ich den jetzt immer (in 1377 und 1382):
$mh{thrRpt} = $RepSndActive;

Hab natürlich keine Ahnung wozu das gedacht war. Zumindest kommen jetzt keine Meldungen mehr und meine Ventile funktionieren noch.

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,

ZitatIrgendeine Idee?
Ja, ist nur eine Warnung.
Aus meiner Sicht gibt die fhem.pl Funktion AttrVal in dem Fall, dass der erste Parameter (devicename) nicht definiert ist, zwar den Ersatzwert $default zurück, aber es tritt die obige Warnung auf, weil der Parameter ungeprüft für einen Hash Zugriff verwendet wird.
Das wäre durch Rudolf in der fhem.pl zu verbessern.
Z.B. in dieser Art:
sub
AttrVal($$$)
{
  my ($d,$n,$default) = @_;
  if (defined($d)) {
    my $a = $attr{$d};
    if (defined($a) && defined($n)) {
      $n = resolveAttrRename($d, $n);
      return $a->{$n} if(defined($a->{$n}));
    }
  }
  return $default;
}


Gruß, Ansgar.

yersinia

Hi noansi,

ich hatte es schon unter SlowRF kurz angefragt weil ich die Fehlermeldung in mit bezug auf FS20 vermutete. Ich habe eine Fehlermeldung nach einem normalen FHEM-Update mit Bezug auf FS20:
2021.11.26 11:20:06 0: ERROR: Cannot autoload FS20V
2021.11.26 11:20:06 1: PERL WARNING: Illegal hexadecimal digit 'm' ignored at ./FHEM/10_FS20.pm line 439.

Da ich verbose auf 3 und ohne stacktrace fahre, sind die Zeilen wahrscheinlich wenig aussagekräftig:
2021.11.26 10:41:12 3: CUL_HM set KellerfensterGarten getConfig noArg
2021.11.26 10:41:44 2: HMinfo hm get:configCheck :-f,^(KellerfensterGarten|KellerfensterGarten)$
2021.11.26 11:20:06 0: ERROR: Cannot autoload FS20V
2021.11.26 11:20:06 1: PERL WARNING: Illegal hexadecimal digit 'm' ignored at ./FHEM/10_FS20.pm line 439.
2021.11.26 12:18:19 3: HMinfo hm get:update :
2021.11.26 12:18:19 3: CUL_HM set ActionDetector update noArg
2021.11.26 12:18:19 3: CUL_HM set VCCU update noArg


rudolfkoenig vermutet dies eher hier zu adressieren. Bis jetzt kann ich keine Funktionseinbußen feststellen.
Ich nutze deine tsculfw v39 und v94 der Module von dir (also imho aktueller Stand).

Bevor ich mit stacktrace und verbose 5 anfange würde ich das gern weiter eingrenzen um die Fehler besser nachstellen zu können.

Hast du eine Idee, wie ich der Fehlermeldung weiter nachgehen könnte?
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

noansi


gamauf

Hallo!
Hat es die, hier besprochene, "Timestamp Option" inzwischen in die reguläre, aktuelle CUL-FW (http://culfw.de/culfw-1.67.tar.gz) (und 00_CUL.pm)geschafft?
Bzw. welche CUL-FW wäre für HomeMatic, nach heutigem Stand, zu empfehlen?
Danke!
LG
Rainer

hmtec99

#1288
Hallo noansi!

Kannst du bitte die Version 0.37 noch einmal bereitstellen? Leider wurde der Anhang aus dem entsprechenden Beitrag entfernt...  :(

Ich wollte mal wieder mutig sein und habe die 0.39 installiert. Danach ging gar nix mehr. Keine Verbindung mehr zu Geräten.
CUL (Original V3) auf Overload und nach ca. 20- 30 Sekunden Absturz FHEM. Reproduzierbar.

Also die 0.38 geflashed und installiert. Funktion wieder da, allerdings nur Empfang und kein Senden mehr. Dafür ständig folgende Log-
Einträge:

TSCUL_ParseTsHM: CUL_HM HM CCA channel busy error to 1AC751/FD:  05904510 A F004 02506440 00 0C 1B A011 F11234 1AC751 800903 _sfail

Ich hatte das ganze schon einmal versucht mit gleichem Ergebnis und nach endlosem Suchen und "Fummeln" gings plötzlich wieder. Ursache unbekannt. Leider kriege ich es dieses Mal nicht wieder hingefummelt.

Ich weiß leider nicht mehr ob ich vorher auf 0.37 war, aber ein Versuch ist es wert.

Folgende Frage habe ich noch. In der Anleitung finde ich immer folgende Hinweis zum originalen USB CUL V3:

define CUL_868 TSCUL /dev/CUL868_0@12000000 1234

Ich habe mehrfach den Test gemacht diese hohe Baudrate einzustellen. Danach geht nix mehr mit dem CUL. Nur bei 38400 funktiert das Ganze. Irgendeine Idee? Habe ich dadurch Nachteile?

Gruß, Oli

hmtec99

#1289
Letzter Eintrag kann komplett ignoriert werden.

Es war der berühmte letzte Tropfen, der das Fass zum überlaufen gebracht (oder gebraucht) hat.

Ich vermute das mein CUL irgendwie nicht mehr ganz richtig funktioniert hat...

Ich habe mir eine gebrauchte CCU2 geschossen, in ein LAN-Gateway verwandet und zumindest die
Beobachtung eines Tages zeigt mir, daß der Empfang um Welten (!) besser ist.

Lustigerweise funktioniert nun auch der Empfang meiner LaCrosse-Sensoren wieder fehlerfrei. Irgend-
wann ohne erkennbaren Grund wurde manche Sensoren kaum noch empfangen und irgendwann später
betraf das mehr oder weniger alle (aber nur manchmal, was weiß ich?!). Komischerweise auch, wenn der
CUL gar nicht eingesteckt war?! Mysteriös!  :o

Trotzdem danke für die Entwicklungsleistung, die hier und auch in anderen Bereichen erbracht wird!

Gruß, Oli

P.S. Die Module von TSCUL sind immer noch in Benutzung, da ich außer VCCU und Lan-Gateway nichts geändert
habe. Macht das Sinn, oder sollte ich wieder die originalen Module verwenden?