Frage zu Begrenze Puffer auf die letzten 64kb - WebSocket->Cutter->RegVar->Skript

Moin,

ich habe mir den Analyzer für HM gebaut und lese damit live die Daten über Web Socket Client → Cutter → RegVar → ein. Das funktioniert auch ohne Probleme. Der Cutter schneidet die Nutzdaten raus links mit {„type“:„telegram“ und rechts mit }}. Im Skript wird dies dann wieder zugefügt, damit die json Darstellung korrekt ist.

Hier die Debugs:

In einigen Fällen, wenn nur das Rauschen (noise) übermittelt wird kommt es u. U. zu den folgenden Warnungen:

16.03.2021 13:46:48 | 30207 | WARNING | Cutter | Puffer > 8kb
16.03.2021 13:46:48 | 30207 | WARNING | Cutter | Begrenze Puffer auf die letzten 64kb

Da dies das 1. Mal ist, dass ich diese Technik benutze hätte ich gerne gewusst, ob das Verhalten ignoriert werden kann oder ob ich einen Fehler in meinen Überlegungen habe. Ich könnte auf den Cutter verzichten, aber dann würde das Skript im Sekundentakt gestartet, da das Grundrauschen des Funkverkehrs permanent gesendet wird.

Gruß
Hans

Magst du mal dein Skript der RegVar hier posten? Im Prinzip scheinst du RegVar_SetBuffer zu verwenden. Ist dies notwendig? Es wirkt so, als wenn deine Pakete immer sauber ankommen und du eigentlich nichts puffern müsstest?

paresy

Moin paresy,

nein, mit RegVar_SetBuffer wird nicht gearbeitet.

<?

require_once(IPS_GetKernelDir()."scripts".DIRECTORY_SEPARATOR.IPS_GetScriptFile(59153 ));
require_once(IPS_GetKernelDir()."scripts".DIRECTORY_SEPARATOR.IPS_GetScriptFile(14162 ));
require_once(IPS_GetKernelDir()."scripts".DIRECTORY_SEPARATOR.IPS_GetScriptFile(36599));

$IdKategorie = CreateCategoryByIdent(IPS_GetParent(IPS_GetParent($_IPS['SELF'])), "", "Pi_Analyzer_Data", 0);

// wenn das Skript von einer RegisterVariable-Instanz aus aufgerufen worden ist

if ($_IPS['SENDER'] == "RegisterVariable")
{
	// Json Struktur wieder herstellen, da diese vom Cutter
	// gekürzt worden ist, damit nur die echten Daten
	// Telegramme ankommen.
	$Data = '{"type":"telegram"' . $_IPS['VALUE'] .'}}';
	//var_dump($Data);
	//print_r(json_decode($Data, true));

	$DataArray = json_decode($Data, true);
	//print_r(json_decode($Data, true));

	// Java Script time stamp ist mit Millisekungen
	$TimeStamp = $DataArray['payload']['tstamp'] / 1000;
	$RSSI = $DataArray['payload']['rssi'];
	$Type = $DataArray['payload']['type'];
	$FromName = $DataArray['payload']['fromName'];
	$ToName = $DataArray['payload']['toName'];
	$FromSerial = $DataArray['payload']['fromSerial'];
	$ToSerial = $DataArray['payload']['toSerial'];
	$DC = $DataArray['payload']['dc'];

	$FromNameIdent = str_replace(" ", "_", $FromName) . "_RX_Analyzer";
	$ToNameIdent = str_replace(" ", "_", $ToName) . "_TX_Analyzer";
	$FromNameCCUIdent = str_replace(" ", "_", $FromName) . "_RX_CCU";
	$ToNameCCUIdent = str_replace(" ", "_", $ToName) . "_TX_CCU";

	if ($RSSI == 0) return;

	$Log = false;

	switch ($FromName) {

		case "Aussen Feuchte Temp":
		case "Bad BM":
		case "Bad HT":
		case "Bad WT":
		case "Bad Kontakt Dusche":
		case "Bad Kontakt Wanne":
		case "Eingang BM Briefkasten":
		case "Hans Drehgriffkontakt Fenster":
		case "Hans Taster T6":
		case "Keller LM Hof":
		case "Keller LM Luftentfeuchter":
		case "Keller Kontakt Gefrierschrank":
		case "Keller Temperatursensor":
		case "Keller Terrasse":
		case "Keller Ventil Kontakt":
		case "Keller Ventil Motor":
		case "Keller WT":
		case "Kueche Drehgriffkontakt Fenster":
		case "Kueche Kontakt Fenster":
		case "Kueche Kontakt Gefrierschrank":
		case "Kueche Kontakt Schublade unten":
		case "Kueche LED":
		case "Kueche LM GS":
		case "Schlafen BM":
		case "Schlafen Drehgriffkontakt Fenster":
		case "Schlafen Kontakt Fensterklappe":
		case "WC Kontakt Fenster":
		case "WC Kontakt Fensterklappe":
			SetzeRX();
		break;
	}


function SetzeRX()
{
	global $Log, $IdKategorie, $TimeStamp, $Type, $FromName, $ToName, $FromSerial, $ToSerial, $FromNameIdent, $FromNameCCUIdent, $RSSI, $DC;

	SetValueInteger(CreateVariableByIdent($IdKategorie, "", 1, "", $FromNameIdent, 10, "", true, 0, ""), $RSSI);
	$RSSICCU = HMXML_getParamSet_VALUES($FromSerial, 0, false)['RSSI_PEER'];
	SetValueInteger(CreateVariableByIdent($IdKategorie, "", 1, "", $FromNameCCUIdent, 10, "", true, 0, ""), $RSSICCU);

	if ($Log)
	{
		echo date("d.m.Y - H:i:s", $TimeStamp) . " Typ $Type RSSI $RSSI von $FromName an $ToName von $FromSerial an $ToSerial DC ist $DC \n";
		echo date("d.m.Y - H:i:s", time()) . " RSSI Wert CCU $RSSICCU \n";
	}
}

?>

Wie geschrieben habe ich solche Technik bislang nicht benutzt :slight_smile:

Gruß
Hans

Aah. Ich hab das total übersehen, dass diese Meldung vom Cutter kommt. Im Prinzip scheinen irgendwelche Meldungen sehr groß zu sein. Bzw. der Cutter puffert sehr lange, bis er wirklich schneiden darf. Gibt es Pakete bei dir welche >64kb groß sind?

PS: Ist die WebSocket API etwas offizielles, dass es auf der CCU gibt? Das wäre total an mir vorbei gegangen - und viel besser als die aktuelle API die wir nutzen :slight_smile:

paresy

Moin paresy,

nein, die einzelnen Datensätze sind eigentlich nicht sehr lang. Das Grundrauschen sind die Zeilen mit noise und die telegram Zeilen die echten Daten (400 bytes). Es gibt aber kein Trennzeichen im Sinne von \n \r o. ä. Vielleicht ist das der Grund, dass der Cutter so lange puffert bis es zur Grenze kommt. Es funktioniert alles reibungslos.

Bei der API handelt es sich um den AskSin Analyzer XS AskSin Analyzer XS - Der Analyzer als Desktop-App ohne ESP - HomeMatic-Forum / FHZ-Forum zur Untersuchung der Funktelegramme der HM Geräte und CCU :loveips:

Gruß
Hans

Moin paresy,

da die Cutter Meldungen auch aktuell noch auftreten nochmals die Frage, ob ich das einfach ignorieren kann oder ob ich da noch was anpassen muss :slight_smile:

Die empfangenden Daten sind alle korrekt.

Gruß
Hans

Ich denke du kannst die problemlos ignorieren.

paresy