This content has been archived. It may no longer be relevant
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 alles unterstützt wird und wie das funktioniert, Beispiele und Downloads von picoc für Loxmock(picoc4lm, v4.4) und natürlich den Loxmock selbst, gibts nachstehend(v04).
Update: Zusammenfassung aller Loxmock Features, aller Möglichkeiten zum Debuggen und den aktuellsten Stand gibts hier. Nur dort werden weitere Updates gepflegt.
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):
picoc4lmbzw.picoc4lm.exesamt.dll-Dateien- Die beiden Loxmock-script-Dateien
loxmock.cundloxmock_func.c - Das eigene Skript, im Weiteren
myscript.cgenannt.
- 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"
#endifUnd schon kann das Ganze lokal ausgeführt werden. Einfach eine Kommandozeilen-Shell öffnen, 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. |
Um skriptseitig den linken Eingangsteil zu steuern (in Loxone über entsprechend verbundene Bausteine), gibt es die Funktionen lm_setinputtext() bzw. lm_setinput(). Diese sind vorbereitet in der loxmock.c zu finden. Als Parameter dienen Kanal, hartcodierter lokaler Wert, Name/Bezeichner des in Loxone verbundenen Bausteins. Dieser wird im Netzwerkmodus dann live aus Loxone abgefragt. Um Daten ggfls. nach Loxone zurückzuschreiben, kann der Name des auf der rechten Seite verbundenen Bausteins angegeben werden, als zweiter Parameter, nach dem Kanal durch lm_connectOutput().
Diese Möglichkeiten sind weiter unten in den Absätzen Dateninput und Datenoutput noch detaillierter mit Beispielen beschrieben.
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. Mehr Informationen zum Debugging in picoC sind separat beschrieben.
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.
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 so einfügen, dass mit diesen hartcodierten Ergebnissen gearbeitet wird.
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… 😉 Mehr Informationen und Möglichkeiten zum Debuggen finden sich in diesem separaten Artikel.
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 für Windows | |
| loxmock include Skripte |
Wie immer gilt: Fortschritt, nicht Perfektion… Feedback ist also jederzeit willkommen.