Erstellte Forenantworten
-
Beiträge
-
Ich habe bisher nur Rückmeldungen bis zum Galaxy Tab 4, dass es funktioniert. Prinzipiell müsste es noch bei allen Tabs mit Micro-USB-Buchse weiter funktionieren, allerdings hat Samsung bei den aktuellen Tablets die Buchse an die schmale Gehäuseseite verlagert (also keine Querformat-Montage mehr möglich) und teilweise dort noch nicht mal mittig platziert. Für mich scheiden diese Geräte daher schon konstruktionsbedingt aus, weil ich kein Tablet im Hochformat an der Wand hängen haben möchte.
Die URL https://logocontrol:8080/rest/ bringt immer einen 404-Fehler. Das ist nur die Basis-URL, an welche dann noch ein konkreter Service-Request angehängt werden muss, z.B.:
https://logocontrol:8080/rest/devices
Als IP musst du auf jeden Fall die IP deines Raspberry Pis eingeben und nicht die der einzelnen Logos.
Richtig, Änderungen an der config.xml sind nicht nötig, wenn der HTTPS Zugriff auf die WebUI schon funktioniert. Alle Einstellungen werden im NetIO Designer getätigt. Kommst du denn von deinem Handy aus (auf dem NetIO laufen soll) mit dem Browser auf die LogoControl Webseite und zwar über die HTTPS-Adresse auf Port 8080, also z.B.
https://deinname.dyndns.org:8080/?Also prinzipiell sollte es schon gehen, auch wenn andere Umgebungen wie Windows oder Raspbian nicht von mir supported werden. Plattformspezifisch ist im Prinzip nur die libnodave. Wenn du das fertige Binary von libnodave.so aus dem Repo nimmst, achte darauf, dass nur Version 0.8.4.6 funktioniert. Neuere Versionen sind nicht mehr mit der Logo kompatibel!
Ansonsten ist Mono ja grundsätzlich plattformunabhängig, bei mir funktioniert Version 3.10 stabil, mit neueren Versionen hatte ich Probleme mit einem SSL-Bug, der dazu führte, dass der HTTPS-Webservice nicht mehr funktionierte. Evtl. ist das mit aktuellen Mono-Versionen behoben worden, habe das nicht mehr weiterverfolgt, da ich für HTTPS mittlerweile eh einen nginx Reverse Proxy davor geschaltet habe, der auf den normalen LogoControl HTTP-Port weiterleitet und selbst das ganze Handling mit Basic Auth und Zertifikaten übernimmt.
Du liegst mit deiner Vermutung richtig: nur das erste Attribut wird in der Übersicht direkt angezeigt, alle weiteren Attribute nur im Popup-Menü. Ist das erste Attribut vom Datentyp „Bit“ gibt es grüne/rote Kästchen, bei anderen Datentypen (außer bei Rollläden, die haben noch eine Sonderbehandlung) wird das Kästchen weiß und der Analogwert wird in Klammern angezeigt. Beides kombiniert geht nicht. Willst du sowohl Status (ein/aus) als auch Temperatur in der Übersicht sehen, bleibt dir nur 2 Devices anzulegen.
Nein, das geht nicht, wäre aufgrund der Zeitverzögerung über HTTPS und Internet vermutlich auch nicht praktikabel. Wenn du verschiedene Dimmstufen ansteuern willst, solltest du das die Logo machen lassen (also zeitbasiert den Eingang des Dimmers ansteuern) und von Außen über LogoControl z.B. mit einen Analogwert (0-100%) die gewünschte Dimmstufe einfach setzen (oder wenn kein Analogwert gewünscht z.B. 5 Methoden mit 0%, 25%, 50%, 75%, 100%).
Du kannst in deinem Script den REST-Webservice von LogoControl nutzen und mit einem einfachen HTTP-Aufruf über wget oder curl den Wert in eine Variable deines Scripts lesen. Schau dir mal Beispiel 2 des Artikels „Shell Scripte ausführen an. Dort wird mit wget ein Attribut in die Variable „result“ gelesen.
Also wenn du die Eingabe von Attributwerten vom Standard-Browser-Prompt umstellen willst auf was eigenes (z.B. jQuery-Dialog) dann schau dir mal die index.st im Unterverzeichnis Remote/Resources an. Dort gibt es folgende JavaScript-Funktion:
// set attribute function setDeviceAttribute(deviceId, attributeId, attributeName, currentValue) { var newValue = prompt("Attributwert \"" + attributeName + "\" ändern:", currentValue); if (newValue != null) { jQuery.get('rest/devices/' + deviceId + '/attributes/' + attributeId + '/valueText?set=' + newValue); } }Diese müsstest du dann umschreiben und den jQuery Dialog nutzen.
Die jQuery Lib ist eh schon eingebunden, da ich sie für andere Funktionen bereits verwende, da musst du also nichts machen.Ah, sehe gerade, dass deine Funktion aus dem jQuery UI Paket ist. Das ist natürlich noch nicht eingebunden, nur die normale jQuery Lib.Direkt einen Ausgang über die REST-API abfragen geht gar nicht. Absichtlich! Über die API erreichbar sind nur Geräte, Attribute (Zustände) und Methoden (Aktionen). Das ist das Grundkonzept von LogoControl – keinen direkten Zugriff auf Speicheradressen, In/Outputs/Merkern usw. zu ermöglichen, sondern den zu steuernden Dingen konkrete Namen zu geben und diese dann zu verwenden. Du musst also ein Gerät mit einem Attribut anlegen und dort deinen Ausgang konfigurieren.
Beispiel du hast ein Gerät „Flurlicht“. Dieses hat wiederum ein Attribut „Status“. Das Attribut Status bezieht seinen Wert aus dem Ausgang Q3, zeigt also an, ob das Flurlicht (welches an Ausgang Q3 hängt) an oder aus ist. Die REST-API erlaubt dann die Abfrage nach dem „Status“ des „Flurlicht“.
Lies dazu bitte auch den Abschnitt „Konfiguration von LogoControl“ im Artikel Konfiguration.
Nein, du kannst diese Routine nicht löschen, dazu muss der Quellcode geändert werden. Wenn ich diese Prüfung nun raus nehme und LogoControl trotz nicht erreichbarer Logo(s) hochfahren soll, müsste ich dann jedoch auch noch die Logik/Fehlerhandling implementieren, wie sich Weboberfläche und Webservice verhalten sollen, wenn eine der Logos nicht erreichbar ist. Das habe ich mir mit der Prüfung der Einfachheit halber schlicht erspart. Was passiert z.B. mit Devices/Attributen/Methoden einer nicht erreichbaren Logo in der Anzeige? Ausblenden, ausgrauen oder erst bei Klick einen Fehler anzeigen? In der Oberfläche dann eine Liste der erfolgreich verbundenen Logos und der nicht verbundenen anzeigen, bzw. eine allgemeine Fehlerbox? Im Webservice beim Aufruf von Devices/Methoden/Attributen von nicht erreichbaren Logos eine Fehlermeldung ausgeben, dass die Logo nicht erreichbar ist? Welchen Default-Wert haben Attribute von nicht erreichbaren Logos, z.B. bei der Abfrage in Triggern o.Ä.? Du siehst: einfach die Prüfung raus nehmen ist nicht, da braucht es schon ein paar mehr Handgriffe…
Machbar ist das schon, aber aus Gründen der Faulheit bisher nicht umgesetzt 🙂
Das Thema hatten wir hier schon mal:
Logo über LogoControl in Mode run stopKurzzusammenfassung: Nein, ist nicht möglich.
Frage: Warum willst du die Logo überhaupt Stoppen/Starten?
Ganau das! Den Artikel hatte ich letztes Jahr schon angefangen zu schreiben (aber noch nicht veröffentlicht) und nun erst gerade wegen deinem Problem veröffentlicht. Prüft du meine Seite stündlich auf Updates, oder was? 😉 Wenn du mit der Anleitung schon klar kommst probier es einfach mal. Ist halt keine direkte Lösung für dein Problem, sondern eher ein Workaround.
Die wird erst angelegt, wenn es auch was zu loggen gibt. Bei dir gibt es anscheinend keinen Fehler zu loggen…
So langsam weiß ich auch nicht mehr weiter. Zertifikat vom Port entkoppeln (
httpcfg -del -port 8081), logocontrol.cer und .pvk löschen, neu erzeugen und wieder an Port binden (also das, was in der init.sh am Anfang durchgeführt wird) hast du schon probiert?Welche OpenSSL Version ist bei dir installiert:
openssl version?Hm, OK also Zertifikat ist an den Port gebunden, das kann es schon mal nicht sein. Gibt es im Logfile unter /var/tmp/LogoControl.log einen Eintrag beim Starten?
