[wiregate] URL/REST-Interface für Wiregate?

[koend]

Hallo,

Gibt es eigentlich eine Möglichkeit um Befehle über eine URL zum Wiregate/zur cometvisu abzusetzen?

Hintergrund der Frage:
- c't hat über dieses nette Ding berichtet: https://mystrom.ch/de/wifi-button/
- Ist zwar noch nicht außerhalb der Schweiz lieferbar, aber das kommt evtl. noch
- wenn, dann ist er auch über REST zu konfigurieren: https://mystrom.ch/mystrom-for-developers/

curl -v -d "single=<url>&double=<url>&long=<url>&touch=<url>" http://[IP]/api/v1/device/[MAC]

- Der button würde in meinem normalen Wifi hängen; anderes VLAN als die KNX-Installation
- Kommunikation nur über einen Apache Proxy, cometvisu

Habe kurz über den Firefox code inspector in de cometvisu geschaut ob ich da eine direkt benutzbare URL entdecken kann, habe da aber wohl nicht genügend Ahnung für.

Eine Forumssuche zu REST lieferte auch keine Ergebnisse.

Könnt ihr bitte weiterhelfen?

Vielen Dank und viele Grüße

[Chris M.]

Was willst Du denn genau machen?

Mit der CometVisu, bzw. ihrem Backend, kannst Du durch ein normales HTTP GET Request Befehle auf den KNX senden - vgl. https://github.com/CometVisu/CometVi...chreiben_write
Solltest Du das in einem anderen Format haben wollen, so könntest Du auf dem WireGate leicht eine PHP Seite erzeugen die entsprechend übersetzt.

Solltest Du dagegen von der CometVisu aus über einen HTTP GET Request eine URL antrigger wollen, damit darüber etwas passiert - wie z.B. für ITTT - dann kannst Du das URL Trigger Widget verwenden, vgl. http://cometvisu.org/CometVisu/de/la...ger/index.html

Was jedoch nicht trivial ist, ist wenn Du von außen über eine URL eine Aktion auslösen möchtest, z.B. auch über ITTT. Hier müsstest Du in die Firewall ein entsprechendes Loch bohren. Das ist machbar, da sollte man aber genau wissen was man macht.

[koend]

Chris, einmal mehr vielen Dank!!!

Genau den Link zum Protokoll suchte ich. So verstehe ich die cometvisu auch wieder etwas besser. Ich würde mit dem Button einen Wert auf eine GA schreiben wollen, das sollte mit /w?a=...v= kein Problem sein.
Und auf den Tip mit der PHP-Seite hätte ich ja eigentlich selbst kommen können...

Nochmals Dank und Gruß

[StefanW]

Wir integrieren solche Funktionen auch gerne im Timberwolf Server, wir müssen nur davon wissen und das die Kunden sich das wünschen.

Hierzu bitte: Einen Feature-Request mit allen gewünschten Details (und gerne auch wie der Konfig-Bildschirm aussehen soll [weil dann denkt man länger nach und es wird schärfer]) an support at wiregate dot de.

Wir bauen den Timberwolf Server für EUCH. Darum müssen wir wissen, was ihr haben wollt!


lg

Stefan

[blacksavior]

Klasse Angebot! Da ich mir den Timberwolf auf jeden Fall holen werde - dass hätte ich nicht schreiben sollen... nun geht der Preis hoch - würde es meinem Eigenheim zu Gute kommen. Da beruflich solche Schnittstellen selber Baue wie auch fremde anbinde, würde ich mich nur darüber freuen, wenn Ihr Euch stark an einem verbreiteten Standart halten würdet und den WÜnschen der Comunity somit eine Ordentliche Form ohne Sonderlocken gebt. Bspw. an RESTful - ohne wenn und aber. Oder einen anderen Standart Eurer Wahl... auch wenn ich SOAP nicht mag.
Ich sehe leider täglich gut gemeinte aber "dumme" Abweichungen, die dann im Nachhinein für alle nur Mehraufwand bedeuten.

Als Beispiel für die Community: Man "triggert" in der modernen Programmierung per GET nichts an... per GET wird geladen. Möchte ich über eine Schnittstelle etwas auf den Bus schieben, wäre ein POST oder PUT - je nach Kontext - das Mittel der Wahl.

Gruß Oliver

[Gast]

Als Beispiel für die Community: Man "triggert" in der modernen Programmierung per GET nichts an... per GET wird geladen. Möchte ich über eine Schnittstelle etwas auf den Bus schieben, wäre ein POST oder PUT - je nach Kontext - das Mittel der Wahl.

ich bin für UDP :-)

[StefanW]

Guten Morgen Oliver,

Klasse Angebot! Da ich mir den Timberwolf auf jeden Fall holen werde - dass hätte ich nicht schreiben sollen... nun geht der Preis hoch - würde es meinem Eigenheim zu Gute kommen.

Zum Preis: Das größte Limit beim Rollout wird unsere Supportkapazität sein. Die Nachfrage wird daher lange Zeit deutlich höher sein als dass, was wir ausliefern können. In den ersten sechs bis neun Monaten wird nur nach Vorbestellung produziert. Das macht auch die Modellvielfalt erforderlich und ist am Ende für den Kunden kostengünstier, weil keine Lagerhaltungskosten und Risikoaufschläge aufgeschlagen werden müssen. Wir haben das Produkt von vorneherein nicht auf Mengenfertigung ausgelegt, müssen also kein teures Fließband füttern und deswegen über den Preis verkaufen. Rabattschlachten und "Straßenpreise" wird es hier nicht geben. Damit wird unser Produkt interessant für den Wiederverkauf, weil es margenstabil bleiben wird. Damit wird es auch finanzierbar für den Eli, seine Mitarbeiter in eine Schulung bei uns zu schicken. Das breitere Know-How sollte schließlich dem Endkunden zugute kommen. Damit soll eine solide und stabile Basis abseits von Discount und Margenverfall (wie bei so vielen anderen Produkten) geschaffen werden, die eine hohe Supportqualität und eine schnelle und dauerhafte Verfügbarkeit von Ersatzteilen unterstützt.

Da beruflich solche Schnittstellen selber Baue wie auch fremde anbinde, würde ich mich nur darüber freuen, wenn Ihr Euch stark an einem verbreiteten Standart halten würdet und den WÜnschen der Comunity somit eine Ordentliche Form ohne Sonderlocken gebt. Bspw. an RESTful - ohne wenn und aber. ...
Ich sehe leider täglich gut gemeinte aber "dumme" Abweichungen, die dann im Nachhinein für alle nur Mehraufwand bedeuten.

Richtig. man muss es eben richtig gut ausführen. Solange das finanzierbar ist und von der Community getragen wird, gerne. Die Community darf gerne mit darüber abstimmen, wie die Beiträge für die Software-Wartung verwendet werden.

Da Du vom Fach bist: Bitte schick uns einen Feature-Request an support at wiregate dot de. Je ausgefeilter und durchdachter, desto besser verstehen wir was gewünscht ist und desto einfacher können wir die Machbarkeit abschätzen. Zudem kommt es dann auch auf die Abstimmungsliste


lg

Stefan

[blacksavior]

Da Du vom Fach bist: Bitte schick uns einen Feature-Request an support at wiregate dot de. Je ausgefeilter und durchdachter, desto besser verstehen wir was gewünscht ist und desto einfacher können wir die Machbarkeit abschätzen. Zudem kommt es dann auch auf die Abstimmungsliste

In Sachen Featurewünsche Wiregate, KNX und co. stehe ich noch in den Anfängen. Andere Themen des Baus waren wichtiger... aber zumindest steht nun das Übergangs-Wiregate im Rack und wärmt den Platz schon mal für den Timberwolf vor. Sprich: Das fachliche Wissen in Sachen Schnittstellen ist zwar vorhanden, aber was die Community an Funktionen braucht ist bei mir nur schwach vorhanden... Ich schaue aber gerne mal. Falls jemand hierzu Ideen hat, kann er mich gerne per PM ansprechen. Dann fasse ich das mal zusammen und entwerfe einen Vorschlag der Specs für den Server.

StefanW : Darf ich fragen, mit welcher Programmiersprache ihr diesen Part umsetzen würdet? ... bin nur neugierig :-)

Gruß Oliver

[StefanW]

In Sachen Featurewünsche Wiregate, KNX und co. stehe ich noch in den Anfängen. ... Das fachliche Wissen in Sachen Schnittstellen ist zwar vorhanden, aber was die Community an Funktionen braucht ist bei mir nur schwach vorhanden...

Manchmal weiß es die Community auch selbst nicht bzw. ist sich dessen nicht bewusst. Darum ist es sehr sinnvoll mit einem guten Vorschlag, der die eigenen Bedürfnisse abdeckt, anzufangen. Das kann dasn ein guter "Kristallisationskeim" sein, damit andere mti auf den Zug springen und Ihre Wünsche und Vorstellungen dazu stellen.

Selbst die bei der Community erfolgreichsten Kickstarter-Kampagnen brauchen einen Initiator mit einer guten Idee und guter Darstellung um die Massen zu begeistern.

Falls jemand hierzu Ideen hat, kann er mich gerne per PM ansprechen. Dann fasse ich das mal zusammen und entwerfe einen Vorschlag der Specs für den Server.

Ich fürchte, per PN ist es zu wenig interaktiv und reizt die Community nicht zum mitmachen. Mach einen knackigen Vorschlag und sende uns diesen zu (und wir schlagen es dann der Community vor) oder stelle Deinen Vorschlag hier im Forum vor und biete es zur Diskussion an. Wie Du möchtest.


StefanW : Darf ich fragen, mit welcher Programmiersprache ihr diesen Part umsetzen würdet? [/QUOTE]

Mit C, Python und Javascript.

Zur Erklärung:

Die Architektur des Timberwolf Servers besteht aus vielen eigenständigen Modulen mit definierter API und einem Kommunikationssystem zwischen diesen. Damit lassen sich einzelne Module austauschen und erweitern, ohne dass dies die anderen Module berührt.

Diese Module lassen sich drei Gruppen zuordnen: Dem Frontend das im Browser läuft, dem Backend, das die eigentliche "harte" Arbeit leistet und der Middleware, die zwischen Frontend und dem Backend bzw. dem System "vermittelt". Die Frontendmodule greifen nicht direkt auf Systemfunktionen oder Backend-Funktionen zu, sondern nur über die Middleware.

Insofern betreffen größere Erweiterungen immer das Frontend bzw. machen neue Frontend-Module nötig, betreffen auch die Middleware weil die API immer zu erweitern ist und meist braucht man auch noch das Backend und durchaus manchmal spezielle Funktionen in Co-Prozessoren (der Timberwolf 950 hat fünf Co-Prozessoren für Echtzeitaufgaben).

• Frontend-Module werden in Javascript geschrieben (nebst HTML / CSS / LESS usw.)
• Module der Middleware sind in Python oder C geschrieben, das kommt auf Laufzeitverhalten und Speichernutzung an. Die Tendenz geht mittlerweile zu C.
• Backend-Module. die "Engines" sind soweit wie machbar in C geschrieben, manche in Python, wobei letztere durchaus noch nach C migriert werden könnten. Wir tunen gerade die Software und da waren einige Python-Module zu überarbeiten. Zwar kann man schnell damit codieren, aber die Laufzeitunterschiede, insbesondere wenn man keinen PC-Prozessor hat, sind eklatant. Es gibt offenbar schmaleres als C. Einzelne Module sind auch in C++ verfasst, meist weil es eine fertige Bibliothek in C++ dafür gab.

Ich hoffe, Deine Neugier ist damit gestillt.

lg

Stefan