Ankündigung

**saft6luck** · 28.06.2014, 12:44

Kannst du beim nächsten Fehler folgendes testen:

Das EibStudio starten und im "Debugger", je nach Gerät, die Variable cfMini_Connected oder cfAir_Connected lesen. Beim blockierten iPad dann den Wert auf AUS schreiben.

Sollte dies helfen, kann ich dir meinen Patch geben.

**KNXFan1970** · 28.06.2014, 18:00

Danke für deine Antwort. Mit der aktuellen .lib hab ich keine Verbesserung. Jetzt habe ich mal eine ältere Version V1.016 Rev.1.8 genommen. Merkwürdigerweise scheint es damit stabiler zu laufen und dein Tipp funktioniert auch. Könntest du mir bitte deinen Patch zur Verfügung stellen. Ich versuche einfach das Problem immer weiter einzugrenzen.

**saft6luck** · 28.06.2014, 21:38

Ist zwar schon länger nicht mehr in Verwendung, da ich den CommandFusion wesentlich umgebaut habe, sollte aber eigentlich in allen Varianten den Fehler "kaschieren" helfen:

[highlight=epc]
//------------------------------------------------------------
//
// Next Telegramms in MQueue: Commands to schedule
//
// We provide a small delay, to keep processing alive, if
// Bustransfers are performed each time a Messages is arriving
//-------------------------------------------------------------

if delay(change(Name_Next),2000u64) then {
if ( size(Name_MQueue) != 0u16 ) then Name_Next=!Name_Next endif
} endif

[/highlight]

Such in der EnertexCommandFusion.lib diesen Kommentar und füg das if-then ein.

Problem: Der Manager bleibt stehen und bearbeitet die Queue nicht mehr. Neue Kommandos kommen zwar rein, bleiben aber in der Queue stecken.

Über den Patch wird nach 2sec die Verarbeitung wieder angestoßen. Die Zeit kann man auch kürzer wählen, z.B. 200ms.

**KNXFan1970** · 28.06.2014, 22:57

Danke - probiere ich morgen gleich mal aus.
Darf ich noch fragen, was du mit CommandFusion wesentlich umgebaut meinst?

**saft6luck** · 29.06.2014, 09:58

Bei mir werden alle Geräte gleich konfiguriert, d.h. die Joints werden per Makro nur einmal festgelegt.

Es gibt ein Management-Makro und pro Gerät ein Konfigurations-Makro.

Kommandos werden ein einer Queue empfangen, an die Joints übergeben (ähnlich wie jetzt auch) und dort werden die Antworten in eine Sende-Queue gestellt.

Die Sende-Queue wird abgearbeitet und generiert für jedes eingeloggte iPad die Antwort.

Vorteil:
- Wesentlich stabiler und wesentlich weniger Rechenleistung bei mehreren Geräten.
- Kein langwieriges und umständliches erstellen und warten von mehreren Konfiguration (pro weiterem Gerät ein Makro mehr)

Nachteil:
- Wenn man unterschiedliche CF-Konfigurationen auf den Geräten hat, gelten die Joints global für alle Konfigurationen. Hat man dann für jedes Gerät unterschiedliche Joints, ergibt sich kein wirklicher Vorteil durch diese Konfiguration.
- Alle ausgehenden Nachrichten (Joints) werden an alle eingeloggten Geräte verteilt, auch Inits (was den CFs nichts ausmacht, die verwerfen unerwünschte Nachrichten schneller als sie der eibPC generieren kann

).

**KNXFan1970** · 29.06.2014, 10:25

Das klingt ziemlich cool und effizient - zumal, wenn mehrere Geräte mit der gleichen Konfiguration zum Einsatz kommen bzw. kommen sollen. Hast du schon mal darüber nachgedacht dies - in welcher Form auch immer (also frei oder "aufwandsentschädigend") - zur Verfügung zu stellen?

Ich jedenfalls hätte Interesse.

**saft6luck** · 29.06.2014, 12:57

Ja, kommt sicherlich. Wird noch ein paar Tage dauern, wenn nicht zu viele Dienstreisen dazwischen kommen.

**KNXFan1970** · 29.06.2014, 13:33

Das ist toll - dann will ich mich mal in Geduld üben - auch, wenn's schwer fällt

Vor kurzem habe ich mich selbst auch mal mit der Makro-Programmierung beim eibPC auseinandergesetzt und empfand den Workflow schon recht aufwendig, um kleine Makros (hatte mich an einer Hue-Steuerung versucht) fehlerfrei zu erstellen. Zumal ja ein Test nur am produktiven eibPC erfolgen kann (na ja - außer man leistet sich noch einen zweiten für Tests). Eine Art Simulator-Software wäre hier sicherlich hilfreich. Das ist aber keine Kritik am enertex-Team - der eibPC ist schon ein tolles Device mit einem guten Preis-Leistungs-Verhältnis aus meiner Sicht.
Was ich damit sagen will ist, dass ich allergrössten Respekt davor habe, wenn sich jemand hier größeren Projekten stellt.

**KNXFan1970** · 11.09.2014, 06:12

Zitat von saft6luck Beitrag anzeigen

Ja, kommt sicherlich. Wird noch ein paar Tage dauern, wenn nicht zu viele Dienstreisen dazwischen kommen.

Bitte nicht falsch verstehen! Wollte mich nur mal erkundigen, ob du voran kommst mit deinem Projekt...

Gruß
Frank

**saft6luck** · 11.09.2014, 06:32

Zitat von KNXFan1970 Beitrag anzeigen

Bitte nicht falsch verstehen! Wollte mich nur mal erkundigen, ob du voran kommst mit deinem Projekt...

Das Makro läuft jetzt seit 2 Monaten stabil, bis auf den 1. Connect nach dem Start des CF, wo teilweise Sekundenlang die Antworten des CFs an den eibPC ignoriert werden. (Man kann schalten, Reaktionen bleiben dann bis max. ca. 30 Sekunden aus.)

Da es nach dieser Wartezeit (die auch nicht immer auftritt) sehr stabil läuft, kann ich das verschmerzen.

Mit der Veröffentlichung warte ich momentan nur noch auf den neuen EibParser und ob sich der Fix für das connect-Problem auch hier wirkt.

Ich könnte dir am Sonntag Abend die aktuelle Version schicken, falls du auch testen willst ...

**KNXFan1970** · 11.09.2014, 06:52

Zitat von saft6luck Beitrag anzeigen

Das Makro läuft jetzt seit 2 Monaten stabil, bis auf den 1. Connect nach dem Start des CF, wo teilweise Sekundenlang die Antworten des CFs an den eibPC ignoriert werden. (Man kann schalten, Reaktionen bleiben dann bis max. ca. 30 Sekunden aus.)

Da es nach dieser Wartezeit (die auch nicht immer auftritt) sehr stabil läuft, kann ich das verschmerzen.

Genau das ist auch mein Problem mit den bisherigem Ansatz (nutze die verfügbaren CF Makros). Ich habe die iPads bisher nicht an die Wand gebracht und starte die Visu bei Bedarf. Gleicher Effekt wie bei dir - man kann schalten, aber die Reaktion auf sichtbar ausgeführten Schaltvorgang (Lampe geht tatsächlich an)

wird in der Visu erst nach einer gefühlten Ewigkeit angezeigt. Nach einigen Minuten läuft es dann plötzlich stabil und flüssig.
Habe heute morgen meinen wireshark Mitschnitt an enertex geschickt. Mal sehen ob das Rückschlüsse für die enertex-Leute ergibt. Je nach deren Statement würde ich mich dann auch an das Commandfusion-Team wenden. Weil es so einfach keinen Spass macht...

Zitat von saft6luck Beitrag anzeigen

Mit der Veröffentlichung warte ich momentan nur noch auf den neuen EibParser und ob sich der Fix für das connect-Problem auch hier wirkt.

Ich könnte dir am Sonntag Abend die aktuelle Version schicken, falls du auch testen willst ...

Würde es sehr gern testen - dein Ansatz klingt ziemlich interessant insbesondere was die zukünftige Wartung und Erweiterung betrifft.
Und wenn sich dann das connect-Problem noch lösen lassen würde

Wow!

**GoldenEye** · 02.11.2014, 10:11

Hallo KNXFan1970 / saft6luck

Seid hier einen Schritt weitergekommen? Zwar läuft CF/EIBPC mit den Makros sehr stabil - was aber wirklich stört, ist die mehrere Sekunden dauernde Reaktionszeit beim Start des CF Client.

Ich bin mir am Überlegen, teilweise auf den EIBPC zu verzichten und das Ganze so umzubauen, dass CF die KNX-Befehle mit dem KNXnetIP-Plugin direkt an den Bus sendet.

Habt ihr damit allenfalls bereits Erfahrungen gesammelt?

Gruss, G.

**saft6luck** · 02.11.2014, 20:25

Zitat von GoldenEye Beitrag anzeigen

Hallo KNXFan1970 / saft6luck

Seid hier einen Schritt weitergekommen? Zwar läuft CF/EIBPC mit den Makros sehr stabil - was aber wirklich stört, ist die mehrere Sekunden dauernde Reaktionszeit beim Start des CF Client.

Du sprichst vom original Makro, oder?

Da das bei mir nicht stabil lief habe ich es umgeschrieben. Diese Version kannst du gerne testen, sie erscheint mir schon besser zu sein, das Problem bleibt aber trotzdem sichtbar. Bei Interesse muss ich dich aber bis zum WE vertrösten oder du bittest KNXFan dir meine Mail(s) weiterzuleiten.

Bei mir liegt das Thema ansonsten für den Moment auf Eis und wenn sich nichts tut werde ich auf den RasPI ausweichen. Der soll eine dauerhafte Verbindung zum eibPC halten und den Server zum CommandFusion spielen. Sind 35 gut investierte EUR denke ich. (HW Workaround für SW Bug hatte ich auch noch nicht

)

Das Plugin habe ich schon angetestet. Gefällt mir nicht, da es die Werte einer Seite über den Bus liest und das dauert natürlich. Da treibt man den Teufel mit dem Beelzebub aus.

**KNXFan1970** · 03.11.2014, 19:52

Zitat von saft6luck Beitrag anzeigen

...

Da das bei mir nicht stabil lief habe ich es umgeschrieben. Diese Version kannst du gerne testen, sie erscheint mir schon besser zu sein, das Problem bleibt aber trotzdem sichtbar. Bei Interesse muss ich dich aber bis zum WE vertrösten oder du bittest KNXFan dir meine Mail(s) weiterzuleiten.

Ich kann die eMails von saft6luck gern weiterleiten - nehme mal an, dass hiermit die Genehmigung von saft6luck vorliegt - schick mir einfach über PN deine private eMail-Adresse.

Zitat von saft6luck Beitrag anzeigen

...
Bei mir liegt das Thema ansonsten für den Moment auf Eis und wenn sich nichts tut werde ich auf den RasPI ausweichen. Der soll eine dauerhafte Verbindung zum eibPC halten und den Server zum CommandFusion spielen. Sind 35 gut investierte EUR denke ich. (HW Workaround für SW Bug hatte ich auch noch nicht

)

Auch ich warte erst einmal ab bis enertex das Problem noch einmal getestet hat. Ansätze dazu scheint es ja nun doch zu geben. Das Makro von saft6luck arbeitet recht gut - ein echter Fortschritt - aber es behebt eben leider auch nicht das Verbindungsproblem beim CF-Init. Bin deshalb im Moment auch auf der Suche nach neuer Hardware bzw. einer anderen Lösung. Schade - weil der Ansatz mit dem eibPC mir eigentlich gefallen hat und dies eigentlich der Grund für die Anschaffung dafür war.

Ankündigung

Commandfusion & eibPC

Commandfusion & eibPC

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar