UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[andibr]

@mcm1957
Ich bin gerade am schauen im Protokoll, ich habe bei meinen Pool (Aussen und Innenwhirlpool) jeweils ein eigener Kanal definiert und bei beiden sollte um 08.00 die Filterpumpe in Betrieb gehen. Im Protokoll sehe ich aber, dass nur der Wihrlpool eingeschaltet hat.

2024-07-14 08:00:00.004 - debug: time-switch.0 (15207) Executing trigger TimeTrigger {id=0, hour=8, minute=0, weekdays=[1,2,3,4,5,6,0]}
2024-07-14 08:00:00.005 - debug: time-switch.0 (15207) Setting state 0_userdata.0.Daten.Schaltuhr.WihrlpoolFilter with value true

Dafür um 08.30 dann eine ganze Zeile an Enträgen:

2024-07-14 08:30:25.470 - debug: time-switch.0 (15207) Received change-switched-ids
2024-07-14 08:30:25.471 - debug: time-switch.0 (15207) {"dataId":"time-switch.0.onoff.2.data","stateIds":["0_userdata.0.Schaltuhr.pool_ein"]}
2024-07-14 08:30:25.499 - debug: time-switch.0 (15207) Got coordinates lat=46.xxxxxxxxxxxxxxxxxxx long=9.xxxxx
2024-07-14 08:30:25.500 - debug: time-switch.0 (15207) Register trigger TimeTrigger {id=AstroTriggerScheduler-Rescheduler, hour=2, minute=0, weekdays=[1,2,3,4,5,6,0]}
2024-07-14 08:30:25.502 - debug: time-switch.0 (15207) Finished message change-switched-ids
2024-07-14 08:30:25.583 - debug: time-switch.0 (15207) Received change-switched-values
2024-07-14 08:30:25.584 - debug: time-switch.0 (15207) {"dataId":"time-switch.0.onoff.2.data","valueType":"boolean","onValue":"true","offValue":"false"}
2024-07-14 08:30:25.631 - debug: time-switch.0 (15207) Got coordinates lat=46.xxxxxxxx long=9.xxxxxxxx
2024-07-14 08:30:25.632 - debug: time-switch.0 (15207) Register trigger TimeTrigger {id=AstroTriggerScheduler-Rescheduler, hour=2, minute=0, weekdays=[1,2,3,4,5,6,0]}
2024-07-14 08:30:25.636 - debug: time-switch.0 (15207) Finished message change-switched-values
2024-07-14 08:30:25.659 - debug: time-switch.0 (15207) Ignoring state change for time-switch.0.onoff.2.data with ack=true
2024-07-14 08:30:25.705 - debug: time-switch.0 (15207) Ignoring state change for time-switch.0.onoff.2.data with ack=true
2024-07-14 08:30:30.425 - debug: time-switch.0 (15207) Received change-switched-ids
2024-07-14 08:30:30.425 - debug: time-switch.0 (15207) {"dataId":"time-switch.0.onoff.2.data","stateIds":["0_userdata.0.Daten.Schaltuhr.WihrlpoolFilter"]}
2024-07-14 08:30:30.461 - debug: time-switch.0 (15207) Got coordinates lat=46.xxxxxxx long=9.xxxxxxxx
2024-07-14 08:30:30.462 - debug: time-switch.0 (15207) Register trigger TimeTrigger {id=AstroTriggerScheduler-Rescheduler, hour=2, minute=0, weekdays=[1,2,3,4,5,6,0]}
2024-07-14 08:30:30.464 - debug: time-switch.0 (15207) Finished message change-switched-ids
2024-07-14 08:30:30.486 - debug: time-switch.0 (15207) Received change-switched-values
2024-07-14 08:30:30.487 - debug: time-switch.0 (15207) {"dataId":"time-switch.0.onoff.2.data","valueType":"boolean","onValue":"true","offValue":"false"}
2024-07-14 08:30:30.657 - debug: time-switch.0 (15207) Got coordinates lat=46.xxxxxxx long=9.xxxxxxx
2024-07-14 08:30:30.660 - debug: time-switch.0 (15207) Register trigger TimeTrigger {id=AstroTriggerScheduler-Rescheduler, hour=2, minute=0, weekdays=[1,2,3,4,5,6,0]}
2024-07-14 08:30:30.664 - debug: time-switch.0 (15207) Finished message change-switched-values
2024-07-14 08:30:30.673 - debug: time-switch.0 (15207) Received change-switched-ids
2024-07-14 08:30:30.674 - debug: time-switch.0 (15207) {"dataId":"time-switch.0.onoff.3.data","stateIds":["0_userdata.0.Daten.Schaltuhr.WihrlpoolHeizung"]}
2024-07-14 08:30:30.730 - debug: time-switch.0 (15207) Got coordinates lat=46.xxxxxxxx long=9.xxxxxxxx
2024-07-14 08:30:30.731 - debug: time-switch.0 (15207) Register trigger TimeTrigger {id=AstroTriggerScheduler-Rescheduler, hour=2, minute=0, weekdays=[1,2,3,4,5,6,0]}
2024-07-14 08:30:30.733 - debug: time-switch.0 (15207) Finished message change-switched-ids
2024-07-14 08:30:30.758 - debug: time-switch.0 (15207) Received change-switched-values
2024-07-14 08:30:30.759 - debug: time-switch.0 (15207) {"dataId":"time-switch.0.onoff.3.data","valueType":"boolean","onValue":"true","offValue":"false"}
2024-07-14 08:30:30.818 - debug: time-switch.0 (15207) Ignoring state change for time-switch.0.onoff.2.data with ack=true
2024-07-14 08:30:30.820 - debug: time-switch.0 (15207) Got coordinates lat=46.xxxxxxx long=9.xxxxxxx
2024-07-14 08:30:30.823 - debug: time-switch.0 (15207) Register trigger TimeTrigger {id=AstroTriggerScheduler-Rescheduler, hour=2, minute=0, weekdays=[1,2,3,4,5,6,0]}
2024-07-14 08:30:30.827 - debug: time-switch.0 (15207) Finished message change-switched-values
2024-07-14 08:30:30.832 - debug: time-switch.0 (15207) Ignoring state change for time-switch.0.onoff.2.data with ack=true
2024-07-14 08:30:30.849 - debug: time-switch.0 (15207) Ignoring state change for time-switch.0.onoff.3.data with ack=true
2024-07-14 08:30:30.928 - debug: time-switch.0 (15207) Ignoring state change for time-switch.0.onoff.3.data with ack=true

Da hat es sogar irgendwelche "Astro-Einträge" drin, aber ich habe alle Blockly kontrolliert, in den Cronjob habe ich immer fixe Uhrzeiten drin. Aus meiner Sicht sollten die Cron aus dem Blockly ja gar nicht unter dem Debug von "time-switch" erscheinen? Vor allem voher kommt die verschiebenung um die halbe Stunde? Ich verstehe das echt nicht.

[DJMarc75]

@andibr

Bitte persönliche Daten wie Lat und Lon entfernen !

[andibr]

@djmarc75 Sorry, habe ich vergessen, aber jetzt korrigiert.

[andibr]

@arteck said in Test Adapter time-switch v2.0.x GitHub/Latest:

@mcm1957 ich hab die 2.3.0-pre.1 ..ja läuft

Ich weiss ob ich auch auf die 2.3.0 wechseln soll? aktuell habe ich ja 2.2.2

[andibr]

Hallo Leute kann es sein, das mein RPI 4 (4G-RAM) mit 2 Schaltpunkten zur gleichen Zeit ein Problem hat?

Ich habe jetzt den einen Pool-Filter auf einschalten "08:01" gestellt, und heute morgen hat es einwandfrei funktioniert.

2024-07-15 08:00:00.002 - debug: time-switch.0 (46262) Executing trigger TimeTrigger {id=0, hour=8, minute=0, weekdays=[1,2,3,4,5,6,0]}
2024-07-15 08:00:00.003 - debug: time-switch.0 (46262) Setting state 0_userdata.0.Schaltuhr.pool_ein with value true
2024-07-15 08:00:49.004 - debug: bestway.0 (46833) {"did":"0PEGsas.........................:1}}

und der andere:

2024-07-15 08:01:00.002 - debug: time-switch.0 (46262) Executing trigger TimeTrigger {id=0, hour=8, minute=1, weekdays=[1,2,3,4,5,6,0]}
2024-07-15 08:01:00.003 - debug: time-switch.0 (46262) Setting state 0_userdata.0.Daten.Schaltuhr.WihrlpoolFilter with value true

Ich denke eher nicht, dass es am Adapter liegen wird und der 2 unabhängige Kanäle zum gleich Zeitpunkt vermischelt, oder per Zufall nur einen Ausführt?

[mcm1957]

@andibr said in Test Adapter time-switch v2.0.x GitHub/Latest:

Hallo Leute kann es sein, das mein RPI 4 (4G-RAM) mit 2 Schaltpunkten zur gleichen Zeit ein Problem hat?

Nur kurz (und nicht ganz im Ernst) geantwortet: JA, das kann natürlich sein

Ich denke eher nicht, dass es am Adapter liegen wird und der 2 unabhängige Kanäle zum gleich Zeitpunkt vermischelt, oder per Zufall nur einen Ausführt?

Na ja - an was sollte das denn sonst leigen als am Adapter :-)

Ich kenn den Adapter nicht und kann ihn im Moment auch kaum warten. Aber wenn du helfen willst, dann versuch das mal mit ein paar Tests zu erhärten und erstell ein Issue mit den Details im Adapter Repo. (Fehlermeldungen im Forum gehen im allgemeinen ohne dazugehöriges Issue unter)

[andibr]

@mcm1957 werde ich nach meinem Urlaub mal etwas erforschen. Vorerst hoffe ich das es in der Abwesenheit richtig geht.

[mcm1957]

@andibr said in Test Adapter time-switch v2.0.x GitHub/Latest:

@mcm1957 werde ich nach meinem Urlaub mal etwas erforschen. Vorerst hoffe ich das es in der Abwesenheit richtig geht.

Schönen Urlaub.
Wird schon OK gehen. Es tritt immer das auf mit dem man nicht rechnet. ioBroker hat beio meinem Urlaub 1a alles gut gesteuert. Nur die Batterie eines Bewässerungsventils hat er nicht gewechselt :-(. Da sind Nachbarn halt wartungsfreier :-)

[andibr]

@mcm1957 danke

@mcm1957 said in Test Adapter time-switch v2.0.x GitHub/Latest:

@andibr said in Test Adapter time-switch v2.0.x GitHub/Latest:

@mcm1957 werde ich nach meinem Urlaub mal etwas erforschen. Vorerst hoffe ich das es in der Abwesenheit richtig geht.

Schönen Urlaub.
Wird schon OK gehen. Es tritt immer das auf mit dem man nicht rechnet. ioBroker hat beio meinem Urlaub 1a alles gut gesteuert. Nur die Batterie eines Bewässerungsventils hat er nicht gewechselt :-(. Da sind Nachbarn halt wartungsfreier :-)

Danke, ich brauche den Urlaub sonst drehe ich bald ab. Bei mir im Job geht es gerade sehr heftig zu.

Da ich nicht Software schreiben kann, kann ich nur testen und protokolieren was wie reagiert. Aber auch das muss ja jemand machen.

Andi

[mcm1957]

@andibr said in Test Adapter time-switch v2.0.x GitHub/Latest:

Da ich nicht Software schreiben kann, kann ich nur testen und protokolieren was wie reagiert. Aber auch das muss ja jemand machen.

Ja DANKE.
Rückmeldung von Problemen und Hilfe beim Eingrenzen ist sehr wertvoll.

Erhol dich mal gut !

[Lucky_ESA]

Hallo zusammen,

wie wichtig wäre es denn diesen Adapter für VIS-2 läuffähig zu bekommen?

Gruß//Lucky

[mane444]

@lucky_esa ich würde mich freuen wenn ich den Adapter mit VIS2 nutzen könnte.
Da ich time-switch benutze kann ich deshalb noch nicht auf VIS2 umsteigen.

[BananaJoe]

@lucky_esa für mich sehr ... ich mache sämtliche Zeitsteuerungen über den Adapter :-)
Wie bei @mane444 ist das einer Gründe (von 2en) das ich die VIS2 bisher links liegen gelassen habe.

[picky]

@lucky_esa Bei mir das gleiche Nutze VIS 2 aus 2 Gründen nicht, weil meine Navigation, und der Time-Switch-Adapter nicht geht ;-)

[Lucky_ESA]

Ich habe leider keine Ahnung von VIS und seine widgets aber warum es nicht funktioniert kann ich sehen. Es gibt leider 2 Themen warum es nicht funktioniert.

1. Das hat was mit diesem issue zu tun. Da hätte ich einen Workaround.
2. Der 2te ist leider etwas schlimmer. Das Thema haben schon einige berichtet, dass man nicht so einfach an die Values eines States kommt. Hier hätte ich einen Workaround der leider etwas umständlich wäre. Man müsste 4 Datenpunkte 2 x auswählen.

[mcm1957]

Die Diskussion zur Weiterentwicklung bzw. zum Adapter TIMER-SWITCH (Lucky_ESA) wurde in einen eignen Thread verlagert:

https://forum.iobroker.net/topic/77355/test-adapter-timer-switch

Bitte hier NUR Beiträge zum älteren Adapter time-switch (ohne "r") verfassen.

[Lucky_ESA]

@mcm1957 Kannst du mir bitte mal einige Fragen beantworten?

1. Wenn ich einen PR erstelle, wirst du diesen Mergen (es werden alle Daten geändert)?
2. Wenn ja, kannst und wirst du dann ein neues Release erstellen?
3. Wenn ja, kannst du dann auch eine neues Release auf NPM ablegen?
4. Wenn ja, kannst du dann einen PR für stable erstellen. Würde dann natürlich eure Änderungswünsche umsetzen.

Gruß//Bodo

[arteck]

@lucky_esa sagte in Test Adapter time-switch v2.0.x GitHub/Latest:

Wenn ich einen PR erstelle, wirst du diesen Mergen (es werden alle Daten geändert)?

das kann ich dir beantworten mit klaren NEIN
der Martin ist kein eingetragener owner von dem Repo...

und der walli545 war schon lange nicht mehr aktiv.. ergo .. der Adapter ist tod. zumindest aus diesem Repo...

[mcm1957]

@lucky_esa said in Test Adapter time-switch v2.0.x GitHub/Latest:

@mcm1957 Kannst du mir bitte mal einige Fragen beantworten?

1. Wenn ich einen PR erstelle, wirst du diesen Mergen (es werden alle Daten geändert)?
2. Wenn ja, kannst und wirst du dann ein neues Release erstellen?
3. Wenn ja, kannst du dann auch eine neues Release auf NPM ablegen?
4. Wenn ja, kannst du dann einen PR für stable erstellen. Würde dann natürlich eure Änderungswünsche umsetzen.

Gruß//Bodo

Wie Artek schon geschrieben hat:

NEIN ich kann das (so) nicht und ziemlich sicher kann es auch sonst niemand.

Damit stell ich mal ein paar Gegenfragen :-)

• Wurden deine Änderungen / Erweiterungen in irgendeiner Form mit dem Owner des Repositories (wally545) abgestimmt?
• Wurde in irgendeienr nachvollziehbaren Form versucht wally545 zu kontaktieren (Issue, Mail, ...)?

Generell kann ein Adapter in den Community Bereich übernommen werden. Dazu ist aber entweder die Zustimmung des derzeitigen Owners notwendig oder es muss zumindest angemessen versucht werden diesen zu erreichen, d.h alle bekannten Kommunikationswege und mindestens 1 bis 2 Monate Reaktionszeit. Du würdest es sicher auch nicht wollen, dass einer deienr Adapter einfach mal so verschoben wird nur weil du krank / auf Urlaub bist.

Weiters ist für die Übernahme in den community Bereich zumindest eine rudimentäre Wartbarkeit / ein zumindest interessierter Maintainer erforderlich, da keiner den Community Adapters Bereich als Ablagerort für Zombies sieht. Dieser Punkt wäre ja gegeben und die allenfalls notwendige Timeoutanfrage bei Wally545 würde ich vornehmen wenn ...

Und damit zur konkreten Situation:
Sollte wally545 zustimmen oder nicht erreicht werden, stellt sich die Frage was du geändert hast.

An sich hast du einen NEUEN Adapter erstellt. Neues Repo, neuer Name -> neuer Adapter. Wenn du nun diesen unter dem alten Namen veröffentlchen willst, wäre interessant was sich geändert hat.
-) wird eine existierende Konfiguration übernommen?
-) bleiben existierende States zumindest Großteils ident erhalten?
-) was verstehst du unter "es werden alle Daten geändert" ?

Hintergrund der Frage ist, ob es sinnvoll ist den alten Adapter zu übernehmen und (ggF) inkompatibel massiv zu ändern oder gleich einen neuen Adapter zu veröffentlichen und den alten Adapter asulaufen zu lassen wenn User sowieso Einstellungen / Vis etc. anpassen müssen.

Für diese Entscheidung fehlen mir derzeit Infos wobei ich gleich sage, dass ich diese nicht alleine treffen werden.

@apollon77 FYI

[Lucky_ESA]

@mcm1957 Leider mache ich immer wieder den gleichen Fehler und konfrontiere, User wie dich, ohne Referenz, sorry...Ich gelobe Besserung.

History:
Bin von diesen Adapter abhängig und da habe ich diesen Issue gesehen.
Hatte dann einen Fork erstellt und schnell festgestellt, dass das schwierig werden wird. Um das alles zu testen habe ich temporär (alles hier im Thread beschrieben) den timer-switch (mit r) angelegt. Wenn alles funktioniert wollte ich ein PR erstellen und den timer-switch löschen (alles hier bereits beschrieben).

Du wurdest, laut Mail, von walli546 eingeladen und hast Rechte für NPM. Wenn du diese Einladung akzeptierst, könntest du einen PR Mergen und ein neues Release erstellen.

Es würde theoretisch ausreichen, eine PR zu mergen und kein Release zu erstellen. Oder den Adapter aus dem Beta Repo werfen.

Natürlich werde ich kein neuen Adapter erstellen oder eine Anfrage bezügl. wechsel in den Community Bereich stellen. Du hast ihn ja angeschrieben und wir haben sein Statement.

Nun zurück zu meinen Fragen:

1. Wenn ich einen PR erstelle, wirst du diesen Mergen (es werden alle Daten geändert)?
2. Wenn ja, kannst und wirst du dann ein neues Release erstellen?
3. Wenn ja, kannst du dann auch eine neues Release auf NPM ablegen?
4. Wenn ja, kannst du dann einen PR für stable erstellen. Würde dann natürlich eure Änderungswünsche umsetzen.

Wenn du das nicht möchtest, dann lass ich den Fork bestehen.

Gruß//Lucky