Umfrage: Amazon Echo

[hotzen]

psilo das ist aber ein workaround, keine lösung auf /alexa zu gehen. die plugins reagieren dann gemeinsam auf die registrierten pfade - kollisionen gibt es dann nur nicht, wenn sich alle plugins absprechen - oder?

ich schaue mir deinen link an, danke für die analyse.

requirements sind da, simplejson ist draussen - gepushed

[psilo]

hotzen naja wenigstens laufen jetzt erstmal beide parallel. wenn sich mehr als nur ich durch die api fuchsen, kriegt man das sicher auch noch hin

ps: mit umbau meinte ich auch, auf die server.start() impl zu wechseln sehe gerade, das ist drin

[mode]

Wäre die Möglichkeit des VHost Distpacher kein gangbarer Weg? Gut, dann müsste man einen konfigurierbaren DNS Server für die lokalen Hostnamen haben, wo eine Dummy Subdomain für den alexa Endpunkt konfiguriert werden kann aber das würde mich jetzt nicht stören.

Also so:
server.home:1234 -> Backend
alexa.server.home:9000 -> Alexa
beide DomainNamen zeigen auf die IP des Smarthome.py Servers.

[psilo]

mode ich will noch nicht so recht glauben, dass ich nicht pro port / server andere object-trees hinterlegen kann

brauche ich bei dem vhost wirklich subdomains? kann ich nicht einfach die untersch. ports mappen?

Also so:
server.home:1234 -> Backend
server.home:9000 -> Alexa

wie hier bspw:

vhost = cherrypy._cpwsgi.VirtualHost(
    RootApp,
    domains={
        'www.domain2.example': Domain2App,
        'www.domain2.example:443': SecureApp,
    },
)

[psilo]

Ich gebe für heute mal auf. Vielleicht kommt bis morgen eine neue Idee oder jemand anders testet weiter.

Ich teste morgen mal das VHost Thema weiter durch und baue im Backend ein, dass man den Pfad konfigurieren kann, so dass es dann via /backend läuft. Nur für die "static" Dateien wird das nicht gehen.

[mode]

Hab gerade mal ein kleines Test Programm geschrieben. So wie es aussieht funktioniert das mit den VHosts nicht ohne weiteres "Portübergreifend". Schade

Edit: Ich gebe auch auf und gehe zum Griechen um meinen Frust in Gyros und Tzaziki zu ertränken

[hotzen]

merke jetzt gerade im live-test, dass mein dimmen noch gar nicht funktioniert.

[[ew]]
    [[[couch]]]
    type = bool
    alexa_device = ew_light_couch
    alexa_name = "Couch"
    alexa_description = "Couch-Deckenlampe im Wohnzimmer"
    alexa_actions = "turnOn turnOff"
    knx_dpt = 1
    knx_listen = 1/2/1
    knx_init = 1/2/1
    knx_send = 1/2/0
      [[[[dimmen]]]]
      type = num
      alexa_device = ew_light_couch
      alexa_actions = "setPercentage incrementPercentage decrementPercentage"
      knx_dpt = 5
      knx_listen = 1/2/5
      knx_init = 1/2/5
      knx_send = 1/2/4

das ew.couch.dimmen ist bei mir ein 5.001 Prozent, definiert per DPT und einem Wertebereich von 0..255.
Die jetztige Implementierung geht noch alpha-mäßig von 0..100 aus, so dass 100% zu 39% dimmwert werden....

Ich gehe davon aus, dass das nicht mit

eval

zu heilen ist und ich etwas wie alexa_item_min und alexa_item_max einführen muss, oder habt ihr eine andere idee?

psilo, mode danke fuers testen/workarounden

[hotzen]

habe die cherrypy dependency draussen - gepushed

[psilo]

hotzen ich habe den PR gemerged. Trotzdem wäre meine Bitte, die Version auf 1.3.0.8.0 zu ändern, da wir laut Konvention die Version des SHNG, ab dem das Plugin aktiv wird, mitziehen. Bspw. wegen am CORE benötigten features..

Ein Umbau auf get_iattr_value wäre auch noch klasse, auch wenn das eigentlich nur bei Multiinstanzfähigen Plugins sich auszahlt. So wären wir bei neuen Plugins aber konsequent.

Bitte trage das Plugin auch unter https://github.com/smarthomeNG/smarthome/wiki/Plugins ein bzw. checke meine Vorarbeit. Dieser Thread hier wäre dann der Supportthread? Idealerweise auch aus dem README darauf referenzieren.

Zu CherryPy: Zu untersuchen wie es bei Mehrfachnutzung sich verhält war sowieso notwendig, da das sicher nicht das letzte Mal ist.

[patrickgoll]

Ich würde vorschlagen wir machen einen "Release" thread in dem wir dann supporten. Meine ursprüngliche Abstimmung ist dazu nicht geeignet wie ich finde.

[psilo]

patrickgoll mir auch recht, kann das auf der übersichtsseite dann entsprechend ändern. bitte dann noch ins readme eintragen.

[hotzen]

habe einen thread aufgemacht und im readme verlinkt patrickgoll - wäre toll wenn du das Thema weiterhin anführst: https://knx-user-forum.de/forum/supp...n-alexa-plugin

Ansonsten ist Readme und Version angepasst und ich versuche gleich nochmal einen PR zu bauen.

@psilo: "Ein Umbau auf get_iattr_value" sagt mir gar nichts - wie ist das gemeint?

[psilo]

hotzen siehe https://github.com/smarthomeNG/smart...i/SmartPlugin; "Um auf ein Instanzattribut zu prüfen bzw. auf den Wert des Instanzattributs eines Items aus dem Plugin zugreifen zu können, werden die Funktionen has_iattr und get_iattr_value verwendet.". Richtig wichtig ist es erst wenn Multiinstanz ins Spiel kommt, aber eigentlich die neue gekapselte Methode um auf die Itemwerte zuzugreifen.

Zugriff bspw. via
self.get_iattr_value(item.conf, 'avm_data_type')

[hotzen]

puh, schöner oder lesbarer wirds dadurch ja nicht