CUNO in IPS 4.0, Problem mit RegVar

JPaeper · 17. Januar 2016 um 20:52

Hallo Leute,

in meiner Grabbelkiste lag noch ein CUNO. Ich habe also einen Client Socket erstellt, IP und Port eingetragen und gestartet.
Als nächstes habe ich eine Register Variable angelegt, die als übergeordnete Instanz den bennanten Client Socket hat und auf folgendes Skript zeigt:

// wenn das Skript von einer RegisterVariable-Instanz aus aufgerufen worden ist
if ($_IPS['SENDER'] == "RegisterVariable")
{
    // bereits im Puffer der Instanz vorhandene Daten in $data kopieren
    $data  = RegVar_GetBuffer($_IPS['INSTANCE']);
    // neu empfangene Daten an $data anhängen
    $data .= $_IPS['VALUE'];

    // wenn das Trennzeichen ; in $data gefunden worden ist
    if (strpos($data, ';'))
    {
        // $data in durch ; separierte Datensätze zerlegen
        $datasets = explode(';', $data);

        // alle nicht durch ; terminierten Datensätze ausgeben
        for ($i = 0; $i < count($datasets) - 1; $i++)
        {
            echo "empfangener Datensatz: ".$datasets[$i]."
";
        }

        // $data auf den Inhalt des letzten (unvollständigen) Datensatzes setzen
        $data = $datasets[count($datasets) - 1];
    }

    // Inhalt von $data im Puffer der RegisterVariable-Instanz speichern
    RegVar_SetBuffer($_IPS['INSTANCE'], $data);
    SetValueString(32307 /*[CUNO\CUNO Register Variable\AuxMessage]*/, $data);
}

Es handelt sich dabei um das Skript aus der Dokumentation, lediglich die letzte Zeile ist hinzugefügt.

Wenn ich nun etwas „einfaches“ sende (hier die Abfrage der Versionsnummer), dann ist der erste Versuch nicht erfolgreich, weil irgendwelche Dinge empfangen werden, die da wohl nicht hingehören. Der Eindruck ist, das je länger die Zeit der letzten Sendung um so mehr von diesen Zeichen).
Exemplarisch:

TXT: 17.01.2016 20:40:25.00 |               BUFFER | 
HEX: 17.01.2016 20:40:25.00 |               BUFFER | 
TXT: 17.01.2016 20:40:25.00 |             TRANSMIT | V<CR>
HEX: 17.01.2016 20:40:25.00 |             TRANSMIT | 56 0D 
TXT: 17.01.2016 20:40:26.00 |             RECEIVED | ? (ãÅãÅãÅãÅãÅãÅV is unknown) Use one of m B C F i A I G M R T V W X O e f l t u x E c q<CR><LF>
HEX: 17.01.2016 20:40:26.00 |             RECEIVED | 3F 20 28 E3 C5 E3 C5 E3 C5 E3 C5 E3 C5 E3 C5 56 20 69 73 20 75 6E 6B 6E 6F 77 6E 29 20 55 73 65 20 6F 6E 65 20 6F 66 20 6D 20 42 20 43 20 46 20 69 20 41 20 49 20 47 20 4D 20 52 20 54 20 56 20 57 20 58 20 4F 20 65 20 66 20 6C 20 74 20 75 20 78 20 45 20 63 20 71 0D 0A 
TXT: 17.01.2016 20:40:26.00 |               BUFFER | ? (ãÅãÅãÅãÅãÅãÅV is unknown) Use one of m B C F i A I G M R T V W X O e f l t u x E c q<CR><LF>
HEX: 17.01.2016 20:40:26.00 |               BUFFER | 3F 20 28 E3 C5 E3 C5 E3 C5 E3 C5 E3 C5 E3 C5 56 20 69 73 20 75 6E 6B 6E 6F 77 6E 29 20 55 73 65 20 6F 6E 65 20 6F 66 20 6D 20 42 20 43 20 46 20 69 20 41 20 49 20 47 20 4D 20 52 20 54 20 56 20 57 20 58 20 4F 20 65 20 66 20 6C 20 74 20 75 20 78 20 45 20 63 20 71 0D 0A 
TXT: 17.01.2016 20:40:27.00 |               BUFFER | 
HEX: 17.01.2016 20:40:27.00 |               BUFFER | 
TXT: 17.01.2016 20:40:27.00 |             TRANSMIT | V<CR>
HEX: 17.01.2016 20:40:27.00 |             TRANSMIT | 56 0D 
TXT: 17.01.2016 20:40:28.00 |             RECEIVED | V 1.44 CUNO868<CR><LF>
HEX: 17.01.2016 20:40:28.00 |             RECEIVED | 56 20 31 2E 34 34 20 43 55 4E 4F 38 36 38 0D 0A 
TXT: 17.01.2016 20:40:28.00 |               BUFFER | V 1.44 CUNO868<CR><LF>
HEX: 17.01.2016 20:40:28.00 |               BUFFER | 56 20 31 2E 34 34 20 43 55 4E 4F 38 36 38 0D 0A 
TXT: 17.01.2016 20:40:28.00 |               BUFFER | 
HEX: 17.01.2016 20:40:28.00 |               BUFFER | 
TXT: 17.01.2016 20:40:28.00 |             TRANSMIT | V<CR>
HEX: 17.01.2016 20:40:28.00 |             TRANSMIT | 56 0D 
TXT: 17.01.2016 20:40:29.00 |             RECEIVED | V 1.44 CUNO868<CR><LF>
HEX: 17.01.2016 20:40:29.00 |             RECEIVED | 56 20 31 2E 34 34 20 43 55 4E 4F 38 36 38 0D 0A 
TXT: 17.01.2016 20:40:29.00 |               BUFFER | V 1.44 CUNO868<CR><LF>
HEX: 17.01.2016 20:40:29.00 |               BUFFER | 56 20 31 2E 34 34 20 43 55 4E 4F 38 36 38 0D 0A

Beim zweiten oder dritten Versuch klappt es dann immer…

Direkt vor dem Senden (hier der womöglich relevante Codeteil) leere ich auch noch mal den Buffer:

Regvar_setBuffer($CUNO_ID, "");
IPS_Sleep(150);
$result = RegVar_SendText($CUNO_ID, $Sendung);

Wo liegt der Fehler?

Joachim

Nall-chan · 17. Januar 2016 um 21:18

Das ganze Konstrukt paßt aber nicht zu dem Protokoll und wie du es verarbeitest.

Zuerst darfst du den Buffer nicht leeren beim Senden. Diese ist nur für das Empfangen von Daten.
Du würdest also Daten verlieren !
Dann stimmt das Trennzeichen nicht. Das Original-Skript nutzt ein Semikolon, du brauchst aber 0x0A und musst dann noch ein Zeichen von hinten wegschneiden um die Rohdaten zu erhalten.
Diese werden dann auch in der For-Schleife mit dem echo verarbeitet und nicht am Ende. Das ist der ‚Rest‘ welche wieder in den Buffer geschrieben wird.

Der erste Sendeversuch sieht wirklich komisch aus. Ich würde da mal den Debug vom Socket ansehen und nicht von der RegVar um einen Vergleich zu bekommen was denn nun wirklich zu dem / von dem CUNO kam.

Michael

JPaeper · 17. Januar 2016 um 21:23

Hallo Michael,

Danke für die Antwort und den Tipp. Tatsächlich wird sehr viel gesendet was da nicht hingehört:

TXT: 17.01.2016 21:20:22.00 |             RECEIVED | ? (ãÅãÅãÅãÅãÅãÅãÅãÅãÅV is unknown) Use one of m B C F i A I G M R T V W X O e f l t u x E c q<CR><LF>
HEX: 17.01.2016 21:20:22.00 |             RECEIVED | 3F 20 28 E3 C5 E3 C5 E3 C5 E3 C5 E3 C5 E3 C5 E3 C5 E3 C5 E3 C5 56 20 69 73 20 75 6E 6B 6E 6F 77 6E 29 20 55 73 65 20 6F 6E 65 20 6F 66 20 6D 20 42 20 43 20 46 20 69 20 41 20 49 20 47 20 4D 20 52 20 54 20 56 20 57 20 58 20 4F 20 65 20 66 20 6C 20 74 20 75 20 78 20 45 20 63 20 71 0D 0A 
TXT: 17.01.2016 21:20:25.00 |             TRANSMIT | ã
HEX: 17.01.2016 21:20:25.00 |             TRANSMIT | E3 
TXT: 17.01.2016 21:20:25.00 |             TRANSMIT | Å
HEX: 17.01.2016 21:20:25.00 |             TRANSMIT | C5 
TXT: 17.01.2016 21:20:33.00 |             TRANSMIT | V<CR>
HEX: 17.01.2016 21:20:33.00 |             TRANSMIT | 56 0D 
TXT: 17.01.2016 21:20:33.00 |             RECEIVED | ? (ãÅV is unknown) Use one of m B C F i A I G M R T V W X O e f l t u x E c q<CR><LF>
HEX: 17.01.2016 21:20:33.00 |             RECEIVED | 3F 20 28 E3 C5 56 20 69 73 20 75 6E 6B 6E 6F 77 6E 29 20 55 73 65 20 6F 6E 65 20 6F 66 20 6D 20 42 20 43 20 46 20 69 20 41 20 49 20 47 20 4D 20 52 20 54 20 56 20 57 20 58 20 4F 20 65 20 66 20 6C 20 74 20 75 20 78 20 45 20 63 20 71 0D 0A 
TXT: 17.01.2016 21:20:36.00 |             TRANSMIT | V<CR>
HEX: 17.01.2016 21:20:36.00 |             TRANSMIT | 56 0D 
TXT: 17.01.2016 21:20:36.00 |             RECEIVED | V 1.44 CUNO868<CR><LF>
HEX: 17.01.2016 21:20:36.00 |             RECEIVED | 56 20 31 2E 34 34 20 43 55 4E 4F 38 36 38 0D 0A 
TXT: 17.01.2016 21:20:38.00 |             TRANSMIT | V<CR>
HEX: 17.01.2016 21:20:38.00 |             TRANSMIT | 56 0D 
TXT: 17.01.2016 21:20:38.00 |             RECEIVED | V 1.44 CUNO868<CR><LF>
HEX: 17.01.2016 21:20:38.00 |             RECEIVED | 56 20 31 2E 34 34 20 43 55 4E 4F 38 36 38 0D 0A

Wie könnte ich das denn unterbinden?

Joachim

Nachtrag: Das was irgendwie „zyklisch“ zwischendurch gesendet wird (von wem oder was?) wird bei der nächsten Befehlsausführung zuerst verarbeitet, was offensichtlich zu diesem Verhalten führt…

Nall-chan · 17. Januar 2016 um 21:38

Dann ist die Lösung doch einfach
Du hast mehrere Geräte welche mit diesem Socket verbunden sind.
Dazu einfach mal in die physikalische Baumansicht wechseln.
Michael

JPaeper · 17. Januar 2016 um 21:46

Hallo Michael,

das war es!!! Vielen Dank!

Auf meinem Testsystem hatte ich mal ein One-Wire-Netzwerk getestet, die I/O-Instanz hatte ich zwar gelöscht, aber irgendwie hat sich der OneWireConfigurator ein neues „Ziel“ gesucht…

Wie auch immer, die Hürde wäre genommen.

Ziel wäre es, so ein Steckdosenset von brennenstuhl darüber zu schalten (433 MHz), mal sehen ob das denn klappt…

Joachim

JPaeper · 18. Januar 2016 um 06:53

…das Schalten der Steckdosen hat sehr schnell funktioniert. (…habe mich selbst sehr gewundert…[emoji41]).
Bekommt man es auch irgendwie hin, das der CUNO registriert, wenn die Fernbedienung betätigt wird?
(dazu müsste er ja auf 433 MHz „lauschen“)

Joachim

tommi · 18. Januar 2016 um 09:23

Es gibt eigene CUL/N für 433Mhz. Das Problem an den umgeschalteten CUx ist, das ihre Antenne eigentlich für die andere Frequenz ausgelegt ist und zum anderen nach dem Umschalten die anderen Frequenzbereiche nicht mehr empfangen werden.

Für den CUN(O) 868Mhz hatte ich auch schon mal Scripte für FS20/HMS usw. gemacht. Eigentlich sollte es ausreichen, die richtige Befehlssequenz dort zu hinterlegen.

Tommi

JPaeper · 18. Januar 2016 um 09:29

Hallo Tommi,

vielen Dank für Deine Antwort.

Der CUNO war vorhanden, die Brennenstuhl-Steckdosen auch, daher bin ich schon sehr glücklich, dass das Schalten so einfach funktioniert. So wie ich die Dokumentation im Internet verstanden habe, wird explizit für die Befehlsausführung auf 433 MHz umgeschaltet, da ich ansonsten alles auf „kabelgebunden“ umgerüstet habe, wäre es nicht schade, wenn der CUNO zukünftig nur noch auf 433 MHz „lauschen“ würde, dann könnte man Schaltzustandsänderungen die über die Fernbedienung ausgelöst werden („nice-to-have“ :D) eventuell eben zur „Statuskorrektur“ im IPS verwenden…

Joachim

Nachtrag:
Habe so etwas gefunden:

f<type>[<data>] "fast" (250kBaud) rf txmit via CC1101 packet handling.
 First switch both devices to fastrf mode with "fr", then send data: fs<data>, e.g. fsHallo
 Reset to "SlowRF": fx, followed by X21
 It can be used to "sniff" RFR packets

Wäre das der „richtige“ Befehl?

tommi · 18. Januar 2016 um 21:02

Aja, den kannte ich noch nicht. Aber das ist für die Datenrate. Nicht für die Frequenz.
Beim kompilieren konnte man die Frequenz setzen, aber mit einem Befehl?
Evtl. kannst Du hier noch ein paar Anregungen für 433Mhz Technik bekommen.

Tommi

JPaeper · 18. Januar 2016 um 22:05

Hallo Tommi,

ich habe hier auch noch etwas gefunden:

Change frequency
FREQ2(0D), FREQ1(0E), FREQ0(0F), Fosc = 26MHz
Fcarrier = Fosc/65536*(FREQ2.FREQ1.FREQ0)

Example: W0F21, W1065, W11E8 (868.35MHz)
W0F21, W1062, W1176 (868.00MHz)
Note: fhem users can set it with "set CUL freq 868.3" (868.3 is default)

…muss ja vielleicht doch irgendwie funktionieren…

Joachim