Sollte auch mit VIS laufen. Wie bereit gesagt, wird der alte Adapter nicht mehr lange funktionieren.

Gruß//Lucky

deleteChannelAsync
createDeviceAsync
createChannelAsync
createStateAsync

P.S. Das wäre der PR gewesen.

Gruß//Lucky

Nach kurzer Rücksprache wäre folgende Vorgangsweise am sinnvollsten:

Bitte lass den Adapter unter einem neuen Namen in die Repositories eintragen.

Es gibt dann halt einen time-switch und einen timer-switch. GgF kannst du den Namen auch noch etwas unterschiedlicher gestalten - ist aber dir überlassen.

Dann einfach einen PR für LATES Aufnahme erstellen. Damit sind die beiden Adapter entkppelt und du kannst tun / ändern was du magst bzw. dir sinnvoll erscheint. Da du schreibst "es werden alle Daten geändert" macht es für User sowieso keinen Unetrschied ob sie updaten oder neu installieren - neu installieren bitet sogar den kleinen Vorteil dass gezielter migriert werden kann.

Diskussion zum neuen Adapter bitte dann im entsprechenden Topic:

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

Danke dass du mich erinnerst. Hab mich nicht mehr an diese Diskussion erinnert.

wally545 schreibt explizit (https://github.com/walli545/ioBroker.time-switch/issues/163#issuecomment-2079179952)

Die ownership des Repos werde ich aber nicht übertragen. Wenn das für euch nicht passt, könnt ihr es gerne per Fork regeln.

Aus meiner Ansicht macht es keinen Sinn einen Adapter auf diese Art und weise zu warten. Es ist voll OK wenn mehrere Personen an einem Adapter arbeiten - aber eben auch(!) der Owner. Wenn dieser nicht kann / will hat es keinen Sinn "nur" einen Maintainer zu registrieren. Der kann wesentliche Aufgaben mittelfristig nicht wahrnehmen - so kann er z.B. weder das Repo übertragen noch kann er Webhooks eintragen (-> weblate) oder Security Token anlegen / eintragen (-> zB. npm Anbindung). Das Ganze ist und bleibt dann eine halbe Sache die dann im ungünstigsten Augenblick klemmt...

Man könnte nun den Adapter per Override / Fork verlegen - gegen den expliziten Willen das Owners fände ich das aber nicht so super.

ERGO:
Lass doch deinen Adapter (fork unter neuem Namen) neu in die Repositories eintragen. Was spricht da dagegen? Von Adaptern die nur via Github installiert werden können wird explizit abgeraten. Damit stünde deine Arbeit nur experimentierfreudigen Usersn zur Verfügung...

Alternativ schreib ihn selbst an, ob er dir Zugriffsrechte gibt?

@apollon77
Wie siehst du das?

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

@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

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...

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

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

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

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.

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

Gruß//Lucky

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 !

@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 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 :-)

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)

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 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

Bitte persönliche Daten wie Lat und Lon entfernen !