Loxone Config - picoC und Loxmock funken

Lokale Entwicklung mit netzwerkfähigem picoC und Loxmock

Wie immer bei Problemen ist es natürlich am Besten die Ursache zu beheben und nicht mit Workarounds zu leben. Im Falle der lokalen Entwicklung mit picoC und Loxmock bedeutet das: Ich habe mir picoC zur Brust genommen, „loxonifiziert“ und netzwerkfähig gemacht. Das bedeutet, dass picoC weiterhin picoC bleibt, jedoch ergänzt um sämtliche dokumentierten Loxonefunktionen und Netzwerkzugang. Ein Großteil der picoC Entwicklung inkl. Livedaten aus Loxone kann nun also lokal gemacht werden. Was nun alles unterstützt wird und wie das funktioniert, Beispiele und Downloads von picoc für Loxmock(picoc4lm, v4.1) und natürlich den Loxmock selbst, gibts nachstehend(v04).

Aber von vorne: Bis zur Version 03 konnte der Loxmock ausschließlich mit lokalen Daten arbeiten. Die Loxmock Version ab v04 kann sowohl mit hartcodierten, vorgegebenen lokalen Daten arbeiten als auch sich alles live von den TCP-zugänglichen Devices inkl. Loxone holen. Lokal voll funktionsfähig sind TCP, UDP Kommunikation genauso wie die Aufrufe von httpget() und localwebservice() und noch ein wenig mehr…

Wer den Einführungsartikel zu Loxmock bereits gelesen hat, dem wird einiges bekannt vorkommen, manches unterscheidet sich aber. Deshalb beschreibe ich die Dinge teilweise nochmals vollständig. Ach ja, als Konsequenz sind sämtliche Artikel/Skripte upgedated, damit sie mit der neuesten Version des Loxmock lokal arbeiten können: Modbus blockweise lesen, XML Parser und JSON Parser.

Lokale Ausführung des eigenen Skripts mit Loxmock

Folgende Dinge müssen in ein Verzeichnis gelegt werden (alles am Ende des Artikels zum Download):
- picoc4lm bzw. picoc4lm.exe samt .dll-Dateien
- Die beiden Loxmock-script-Dateien loxmock.c und loxmock_func.c
- Das eigene Skript, im Weiteren myscript.c genannt.
Am Anfang des eigenen Skripts wird nun der nachstehende Code eingefügt. Dieser kann im Skript verbleiben, auch wenn das Skript auf den Loxoneserver kopiert wird. Also: Ein Skript für beide Welten.

#ifdef LOXMOCK
    #include "loxmock.c"
#endif

Und schon kann das Ganze lokal ausgeführt werden. Einfach in eine Kommandozeilen-Shell wechseln, in das Verzeichnis wechseln und Skript ausführen:

Unter Windows: picoc4lm.exe -s myscript.c
Unter Linux: picoc4lm -s myscript.c

Allgemeine Konfiguration

Für die Feinjustierung gibt es folgende allgemeinen Einstellungsmöglichkeiten in loxmock.c Die Netzwerkmöglichkeiten, Eingangs- und Ausgangswerte werden später noch detailliert beschrieben.

`LOXMOCK_PRINT_DEBUG`	0/1	Aufrufe von gemockten Loxonefunktionen ausgeben?
`LOXMOCK_EXECUTE_SLEEP`	0/1	sleep()-Aufrufe ausführen und warten oder einfach durchlaufen?
`LOXMOCK_LOCAL_TZDIFF_TO_UTC`	-23 to 23	Zeitzonen Unterschied zur lokalen Zeit
`LOXMOCK_LOCAL_IS_SUMMERTIME`	0/1	Haben wir Sommerzeit?
`LOXMOCK_ENABLE_NETWORKING`	0/1	Netzwerkkommunikation einschalten oder auf lokalen Daten arbeiten?
`LOXMOCK_ENABLE_WRITEBACK`	0/1	Werte an verbundene Loxoneobjekte zurücksenden?
`LOXMOCK_LOXONESERVER`	ip:port	Adresse des Loxoneservers
`LOXMOCK_LOXONEAUTH`	user:password	Basicauth Informationen. Ggfls. auf die Berechtigungen des Users achten.

Allgemeine Bedienung und Debugging mit dem Loxmock

Wird das Skript nun lokal ausgeführt, so kann jederzeit mit Ctrl+C unterbrochen werden. Es wird die aktuelle Skriptzeile mit einem kleinen Hilfetext ausgegeben, man kann beliebige Befehle eingeben und das unterbrochene Skript auch wieder fortsetzen.

Dateninput

Jeder Inputkanal eines Programm-Bausteins kann belegt werden. Entweder mit einer hartcodierten Vorgabe oder direkt mit einer Referenz zu einem Loxone-Objekt. Loxone Objekte können mit Ihrer ID, UUID oder ihrem Bezeichner angegeben werden. Sollte ein Bezeichner Leerstellen enthalten, so gilt folgendes: "so toll" wird zu "so%20toll".

Für einen Überblick über die Möglichkeiten am Besten das nachstehende Bild betrachten. Das Skript liest nur die Inputs aus. Je nach Loxmock-Konfiguration werden die entsprechenden Werte ausgegeben. Man sieht die konfigurierten, mit Loxone verbundenen Eingabekanäle. Falls mit lokalen Daten gearbeitet wird, so wird der Wert im gleichen Aufruf mit gesetzt.

Beim Erstellen gab es eine Latenz zwischen Loxoneanzeige, meinem Skriptstart und einem gemeinsamen Screenshot… 🙂 Aber die Idee sollte klar werden.

Datenoutput

Ausgabekanäle werden in picoC unter Loxone typischerweise mittels setoutput() angesprochen. Man kann seine Ausgaben lokal belassen oder auf Wunsch auch direkt nach Loxone zurückschreiben. Da das auch gefährlich sein kann, muss diese Option neben der Netzwerkaktivierung explizit eingeschaltet werden. Ich denke auch hier wird das mit dem Bild klar. Die Adressierung erfolgt genauso wie beim Input.

Netzwerkkommunikation im Skript

Was geht?

stream_create() mit „/dev/tcp/*“ „/dev/udp*“ und Files(sofern sinnvoll)
httpget()
localwebservice()
getio()
Änderungen an den Eingängen werden so mitgezogen, dass getinputevent() korrekt arbeiten sollte.

Was geht nicht?

stream_create() mit "/dev/syslog" oder "/dev/tty" funktionieren lokal nicht. Logischerweise bleiben RS232/RS485 dem Loxoneserver vorbehalten.
stream_printf() nur gemockt, ohne Funktion

Sofern da noch etwas gebraucht wird oder ergänzt werden soll, bitte gerne Rückmeldung geben.

Arbeiten mit lokalen Daten

Für das Arbeiten mit lokalen Daten gilt nach wie vor das Vorgehen aus dem Erstartikel zu Loxmock. Das heißt: Als Rückgabewerte für httpget(), localwebservice() und Streams kann man mit cli_tcp seine Daten holen und in den Loxmock einfügen.

Für Werte die über die Eingangskanäle des Programmbausteins gesetzt werden sollen, bitte den Abschnitt Dateninput von oben lesen.

Memoryleaks

Das Verhalten des loxmock ist bzgl. der Speicherallokation wie die Loxonefunktionen. Bei Aufrufen von z.B. getinputtext() oder anderen Funktionen mit entsprechenden Rückgabezeigern werden Werte zurückgeliefert, die mittels free() auch wieder freigegeben werden müssen. Erfolgt das nicht, folgt irgendwann die Quittung. Selbst verschuldete Leaks haben natürlich den gleichen Effekt. Wird alles nur oft genug wiederholt, steigt das Programm irgendwann eben aus. Man sieht das unter Windows recht schön im Taskmanager. Startet man das picoC Skript und wartet auch nicht bei den sleep-Statements, werden viele Iterationen in kurzer Zeit durchgeführt. Steigt der Ressourcenverbrauch kontinuierlich, so empfehle ich von einem Produktionsdeployment abzusehen… 😉

Achtung bei Windows: Das ausführende picoc-Programm wird wirklich als picoc.exe angezeigt und ist nicht zu verwecheln mit der „Windows-Befehlsprozessor“ oder „cmd.exe“ o.ä. Anzeige.

Und nun die Downloads

Achtung: Loxmock v04 ist nicht rückwärtskompatibel mit den Versionen davor und benötigt picoc4lm zur Ausführung.

picoc4lm für Linux	picoc4lm_v04.1 Herunterladen
picoc4lm für Windows	picoc4lm_v04.1 Herunterladen
loxmock include Skripte	loxmock_v04 Herunterladen

Wie immer gilt: Fortschritt, nicht Perfektion… Feedback ist also jederzeit willkommen.

Loxone Config – picoC und Loxmock funken