PCHK mit VBA (Access oder Excel)

[BerndR]

...
Ist das in diesem Fall wirklich ein Problem? Ich denke nicht! Jeder Zugriff auf eine DB dauert um Potenzen länger als der Unterschied zwischen nativem und interpretierten Code.
...

Es macht Sinn, wenn man eine "schwache" Hardware einsetzt. Wenn ich einen Schalter drücke, soll das Licht sofort und nicht erst nach einer Sekunde angehen. Außerdem bin ich mir nicht mal sicher, welches .NET-Framework (und ob überhaupt) mein Windows XP Embedded benutzt !?!?! Also lieber bei nativem Code bleiben ... so hält man sich außerdem eine einfache Portierung nach Linux offen .

[Niko]

Die LinHK macht einen sehr guten Eindruck, läuft aber leider nur auf der Fritzbox und auf keinem normalen PC . Außerdem hat sie - wie ich finde - das gleiche Problem wie andere Lösungen die existieren (z.B. IP-Symcon): Man kann Scripte nur mit einem Ereignis triggern ...

Bei LinHK ist das vorerst noch so, da hast Du recht. Aber mit IPS sollte das gehen: Ein Skript wird aufgrund eines Ereignisses (z.B. ein schaltender Binäreingang) getriggert und liest dann einfach in irgendwelchen von IPS verwalteten Variablen die Stati anderer Binäreingänge, Relais, Ausgänge usw. nach und wertet die Bedingung aus.

Schöne Grüße
Niko, bei dem heute morgen die "Schlechtwetter-LED" aus war (abhängig von Status- und Messwertmeldungen), es wird also gehen :w00t:

[BerndR]

Ja, Niko, es geht mit IPS, aber (wahrscheinlich) nur umständlich. Was mache ich, wenn ich bei bestimmten Kombinationen von Binäreingangs-Stati und/oder Relais-Stati Aktionen ausführen möchte? Jetzt bitte nicht sagen, dass ich bei jedem betroffenen Binäreingang und Relaiseingang das gleiche Skript triggern muß und darin die Stati nochmal abfragen muss, um letztendlich meine Aktion auszuführen .

Gruß, Bernd, dem das viel zu umständlich und fehleranfällig wäre ...

[gadal]

Hallo Bernd,

Es macht Sinn, wenn man eine "schwache" Hardware einsetzt. Wenn ich einen Schalter drücke, soll das Licht sofort und nicht erst nach einer Sekunde angehen.

ich stimme dir in dem von dir beschriebenen Fall zu, aber wenn ich die Frage richtig verstanden habe, ging es um einen Datenlogger, der die Daten auswertbar ablegt und nicht um eine Erweiterung der Logik, so wie du sie planst, die natürlich schnell reagieren muss. Daher sollte die nicht erst warten, bis irgendwelche Daten in einer DB stehen.

Also lieber bei nativem Code bleiben ... so hält man sich außerdem eine einfache Portierung nach Linux offen .

Warum portieren, wenn's auch direkt geht? ("Etwas" Rechenleistung vorausgesetzt.) Aber wer eine DB laufen hat, der sollte auch noch die paar Prozent der Rechenleistung für einen Datenlogger-Prozess überhaben.

Also hier nochmal die Frage konkreter: wer würde für nicht zeitnahe Auswertungen einen Datenlogger, so wie oben beschrieben, einsetzen bzw. wer würde noch welche Funktionalität zusätzlich benötigen?

Gruß,
Alex

[Niko]

Was mache ich, wenn ich bei bestimmten Kombinationen von Binäreingangs-Stati und/oder Relais-Stati Aktionen ausführen möchte? Jetzt bitte nicht sagen, dass ich bei jedem betroffenen Binäreingang und Relaiseingang das gleiche Skript triggern muß und darin die Stati nochmal abfragen muss, um letztendlich meine Aktion auszuführen .

Doch, das dürfte wohl so sein. Wobei mit "Stati abfragen" eher ein Nachschlagen in IPS-Variablen gemeint sein dürfte, eine Bus-Abfrage kann man sich hier sicher sparen.

[zitat]Gruß, Bernd, dem das viel zu umständlich und fehleranfällig wäre ...[/zitat]
Stimmt, wenn man sich da mal vertippt/verklickt...

Da ich für die Implementierung meiner (nicht wirklich wichtigen) Schlechtwetter-LED wohl eine Unmenge an LCN-Ressourcen (LEDs, virtuelle Relais, Regler zur Messwertauswertung, Summen) benötigt hätte, ist es jetzt ein Einzeiler in einem Kommentar eines virtuellen Moduls in LinHK geworden.

Schöne Grüße
Niko, der für wichtige Basisfunktionalität dennoch bei den normalen LCN-Logikmöglichkeiten in realer Hardware bleibt

[BerndR]

...
Also hier nochmal die Frage konkreter: wer würde für nicht zeitnahe Auswertungen einen Datenlogger, so wie oben beschrieben, einsetzen bzw. wer würde noch welche Funktionalität zusätzlich benötigen?

Gruß,
Alex

Einen Datenlogger ausserhalb der LinHK würde ICH nicht für so praktikabel halten. Dann muß man ja doch wieder einen weiteren Rechner laufen lassen. Vielleicht macht es Sinn die Daten mit der LinHK in einem einfachen Pipe-Separated-Ascii-Textfile abzulegen. Dieses kann man dann von Zeit zu Zeit in Excel (direkt) importieren !?!?! Hat die LinHK zufällig auch einen FTP-Server an Board? Dann könnte man sich die Ascii-Files direkt runterladen.

Gruß, Bernd.

[gadal]

Hallo Bernd,

Einen Datenlogger ausserhalb der LinHK würde ICH nicht für so praktikabel halten.

Innerhalb der LinHK gibt's ihn ja schon, da müssen wir ihn nicht bauen.
So wie ich Johannes verstanden habe, sucht er u.a. nach einer Lösung um die Daten eben nicht zeitnah auswerten zu können.
Korrigiert mich bitte, wenn ich was falsch verstanden habe.

Dann muß man ja doch wieder einen weiteren Rechner laufen lassen.

Wenn nicht zeitnah, dann muss er auch nicht dauernd laufen.
Das mache ich z.B. mit meinen Heizungsdaten auch so. Wenn ich den Rechner hochfahre, holt er sich die zwischengespeicherten Daten und schreibt sie in eine DB. Dort kann ich sie dann in aller Ruhe auswerten.
Die Lösung hat nichts mit LCN zu tun, aber die habe ich schon. Darum frage ich ja, ob sowas auch für die von der LinHK aufgezeichneten Daten interessant wäre.

Vielleicht macht es Sinn die Daten mit der LinHK in einem einfachen Pipe-Separated-Ascii-Textfile abzulegen. Dieses kann man dann von Zeit zu Zeit in Excel (direkt) importieren !?!?! Hat die LinHK zufällig auch einen FTP-Server an Board? Dann könnte man sich die Ascii-Files direkt runterladen.

Wie schon geschrieben: die LinHK bietet eine URL an, um die Daten runterzuladen. Schau' mal in die LinHK-Doku Kapitel "Integrierter Web-Server -> Spezielle URLs".
Alternativ hätte die FB natürlich auch noch einen FTP-Server (oder wie bekommst du die Visu auf die FB?).

Gruß,
Alex - der merkt, dass doch schon ganz schön viele Features der LinHK dokumentiert sind

[Thomas]

[zitat]Alex - der merkt, dass doch schon ganz schön viele Features der LinHK dokumentiert sind[/zitat]

Alex, ich kann dir nicht widersprechen.

gruss thomas - Datenlogger = State-Dateien, per FTP auch abholbar

[gadal]

gruss thomas - Datenlogger = State-Dateien, per FTP auch abholbar

... und dann in eine DB geschrieben, so dass MS-Access, Excel und Konsorten die Daten schön bunt darstellen können und komplexere Auswertungen möglich sind.
D.h. LinHK erfasst und Datenlogger speichert dauerhaft und stellt (durch die DB ) die Daten mit einer Standard-Schnittstelle (SQL über ODBC) auswertbar zur Verfügung.

Gruß,
Alex

[MartinH]

[zitat=Thomas]gruss thomas - Datenlogger = State-Dateien, per FTP auch abholbar

... und dann in eine DB geschrieben, so dass MS-Access, Excel und Konsorten die Daten schön bunt darstellen können und komplexere Auswertungen möglich sind.
D.h. LinHK erfasst und Datenlogger speichert dauerhaft und stellt (durch die DB ) die Daten mit einer Standard-Schnittstelle (SQL über ODBC) auswertbar zur Verfügung. [/zitat] Dies halte ich auch für den besten Ansatz !
Wir haben hier nur einen etwas unterschiedliche Vorstellung davon, was die Funktion/Schnittstellen eines Datenloggers sein soll.
Die LinHK Logfiles nutzen das json Format um die gewünschten Ereignisse abzulegen.
Diese Daten kann man sich regelmäßig von der Fritzbox abholen und in eine "richtige Datenbank" einfüttern. Dann stehen einem alle Auswertetüren offen.

BTW - Einfache Statistikauswertungen macht auch schon die LinHK Visu (Max., Min, Durchschnitt, ...) in der Verlaufsanzeige.

[zitat] Alex - der merkt, dass doch schon ganz schön viele Features der LinHK dokumentiert sind[/zitat]
Gruß, Martin - der sogar in der LinHK Dokumentation Sachen korrekturliest, die es eigentlich noch garnicht gibt
= wieder 100 Punkte für LinHK :thumbup: