So weit ich das jetzt beobachten konnte bleiben die Properties jetzt erhalten :), gute Arbeit. Das einzige was mir noch auffällt ist das Feld Wert, das wurde normaler Weise gesetzt. Dies ist aber nun nach Neustart leer. Das tut aber der Funktion kein Abbruch es funktioniert trotzdem weil die Properties ja erhalten bleiben. Wenn man dann in die Instanz geht und irgendwas ändert und auf Übernehmen drückt steht dann auch wieder der Wert im Objektbaum. Aber wie gesagt ich habe da bisher kein Unterschied feststellen können ob der Wert sichtbar ist oder nicht es funktioniert beide male.
Ich habe die korrigierte Version des Frameworks, in dem auch zahlreiche neue Funktionen enthalten sind, soeben als Version 3.1 veröffentlicht.
Über Feedback freue ich mich.
Release Notes:
https://docs.braintower.de/display/IPSPATAMI/Version+3.1
Hallo patami,
wirklich bewundernswert Deine Arbeit.
Hut ab und Danke 
Ich habe es schon länger mitverfolgt, bin aber erst gestern Abend dazu gekommen dein Framework und die Einrichtungen bei Amazon versuchsweise nachzuvollziehen.
Läuft nun schon Mal, auch wenn es anfänglich etwas verwirrend war/ist.
Etwas klappt aber bei mir noch nicht!
Anmeldedaten habe ich eingegeben, aber es kommt das hier:
![2017-06-05 13_11_44-IP-Symcon Management Console [IPS_Pi3].jpg](https://community.symcon.de/uploads/default/original/3X/0/3/03feff43a21493e12429344674012d9025433c7e.jpeg)
Objektbaum sieht damit so aus:
![2017-06-05 13_17_54-IP-Symcon Management Console [IPS_Pi3].jpg](https://community.symcon.de/uploads/default/original/3X/1/9/191b68d9b80f557e0571ba26b62212bd23ff39d4.jpeg)
Und wieso zeigt die Meldung -> „D:\IP-Symcon\cacert.pem“ auf einem Linuxsystem (Pi3) ?
Einen schönen Pfingstmontag wünsche ich allen.
Gruß aus Berlin
lueralba
Danke für Deine Rückmeldung.
Die Meldungen deuten auf Probleme mit den cURL Requests hin. Diese werden aktuell verwendet, um die Symcon Lizenz und Subskription sowie Symcon Connect und die Public IP zu ermitteln bzw. zu prüfen.
Die Überprüfung von Zertifikaten habe ich absichtlich nicht ausgeschaltet, aber hier scheint es Probleme bei Dir zu geben.
Auf Alexa Skills sollte sich das aber nicht auswirken, im Worst Case schlagen die Timer für die Statusvariablen der Framework Instanz fehl.
Die Frage ist, wieso das bei Dir so ist. Einen hart kodierten Windows-Pfad habe ich jedenfalls nicht verwendet, genauer gesagt werden die entsprechenden cURL Optionen von meinem Code auch nicht gesetzt.
@paresy: Hast Du eine Idee?
Im schlimmsten Fall stelle ich per Hotfix eine Checkbox zur Verfügung, mit der man bei den cURL Requests die Überprüfung des SSL Zertifikats deaktivieren kann (auch wenn das sicher nicht die beste Option ist).
@lueralba, probier mal den aktuellen Code in der „test“ Branch.
Dort kannst Du in der Framework Instanz die Überprüfung von SSL Zertifikaten deaktivieren.
Treffer !
Das Framework aus dem test Zweig (Haken SSL… aus) funktioniert einwandfrei !!!
Edit:
Bin wieder zurück auf den Masterzweig.
Stelle mich gerne zur Fehlersuche zur Verfügung :)#
Gruß lueralba
Hallo, ich denke ich habe ein aehnliches Problem. Wenn ich das Module update kommt ich einen Fehler.
Beim Starten geht alles gut.
Dropbox - Log1.PNG
Dropbox - Log2.PNG
Dropbox - Log3.PNG
PHP.ini sieht so aus :
```php
max_execution_time=30
register_globals=off
error_reporting=E_ALL
memory_limit=32M
auto_prepend_file="/usr/share/symcon/scripts/__autoinclude.inc.php"
short_open_tag=1
curl.cainfo="D:\IP-Symcon\cacert.pem"
soap.wsdl_cache_enabled=0
[DATE]
date.timezone="Europe/Berlin"
[Session]
session.save_handler="files"
session.save_path="/var/lib/symcon/session"
session.auto_start=0
session.name="pt"
Sicher damals aus Windows mit übernommen bei Umzug auf Pi.
Darf ich die Zeile löschen oder verändern ?
Einen „cert“-Ordner habe ich unter „/usr/share/symcon/“ !
Gruß
lueralba
Ja. Die Zeile kannst du löschen. Ab der 4.3 löschen wir die unter nicht Windows Systemen dann automatisch. Cooler Fehler
paresy
Moin,
ich steh hier grad etwas auf m Schlauch. Ich bin krampfhaft dabei den Custom Skill Intent im Amazon Develop Account einzurichten. Klappt bis dahin ganz gut, in Symcon ist die übergeordnete Instanz dafür ja der Amazon Custom Skill. Wie jeodch richte ich diesen bei Amazon ein? Alles was ich bisher finde ist nur, wie das ganze in Symcon eingerichtet wird, nicht jedoch in Amazon. Vielen Dank im Voraus.
Grüße Thomas
Ok vielen Dank. Nun hats funktioniert.
GrüßeThomas
Zeile gelöscht
Neugestartet
und läuft
Danke sehr 
Hallo
Kann mir jemand weiterhelfen.
Immer wenn ich versuche die Alexa Custom Skill Webhook Instanz hinzu zufügen kommt folgender Fehler.
Es wird zwar trotz Fehler die Instanz angelegt jedoch wenn ich versuche wie in der Anleitung beschrieben die LaunchRequest zu verknüpfen kommt Fehler „Eigenschaft LaunchRequestIntentID nicht gefunden“.
Hat jemand eine Idee was ich falsch mache
Welche Version verwendest Du?
Unten in der Instanz wird diese angezeigt. Das sieht so aus:
![2017-06-16 18_36_26-IP-Symcon Management Console [172.20.20.12].png](https://community.symcon.de/uploads/default/original/3X/c/3/c37ce01214c616a4d00161329e5a2e0352614e17.png)
Mach bitte mal einen Screenshot davon.
Ich habe dafür immer noch keine Lösung gefunden.
In meinem Framework werden andere Instanzen in den Listen von Instanzen verwendet.
Bei ApplyChanges werden diese Instanzen geprüft bzw. Properties abgefragt.
Das schlägt fehl und führt dazu, dass die prüfenden Instanzen einen Fehlerstatus bekommt.
Was kann ich tun?
Ich löse das jetzt (anscheinend erfolgreich) wie folgt:
- In IPSModule::ApplyChanges() registrieren meine Module sich auf IPS_KERNELSTARTED
- Wenn in IPSModule::ApplyChanges() der Kernel ist nicht KR_READY ist, wird nichts gemacht
- Beim Aufruf von IPS_KERNELSTARTED wird IPS_ApplyChanges() aufgerufen
- Wenn in IPSModule::ApplyChanges() andere Instanzen angesprochen werden müssen (was nur nach dem Kernelstart vorkommt), registriere ich mich auf die IM_CONNECT Nachricht der Instanzen und reagiere auf deise auch wieder mit IPS_ApplyChanges() meines Moduls
- Das Neuladen meiner Bibliothek führt bei Zugriffen auf andere Instanzen beim Modul Update dazu, dass weiterhin InstanceInterface Fehlermeldungen kommen und die Prüfungen der anderen Instanzen fehlschlagen. Die IM_CONNECT Meldungen scheinen das Problem dann aber zu lösen, die Fehlermeldungen haben (außer den Meldungen) keinen negativen Effekt, wie mir scheint.
Ist das so OK?
Gibt es einen Weg, ähnlich wie den Kernelstart die Neuregistrierung des Moduls bzw. das Ende dessen zu erkennen und ApplyChanges() bis dahin zu unterbinden? Die Idee mit der Abfrage des Instanzstatus == 201 tut leider nicht, bei nicht bereiten Instanzen ist dieser trotzdem 102…
Danke für deine Antwort anhand deines Screenshots erkenne ich das es bei mir ganz anders aussieht, werde sobald ich Zeit habe das ganze noch einmal von vorne beginnen.
Ich denke, du nutzt noch das alte Repo.
Versuch mal das:
System Information Custom Skill - Patami IP Symcon Framework - Braintower Docs