Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[TT-Tom]

@Oli

Die Fahrplandaten sind die selben. Ich biete für Abfahrten und Verbindungen Widgets an.
Da der Fahrplan-Adapter zur Zeit nicht gepflegt wird, habe ich mich entschieden einen eigenen zuschreiben.

Bin jetzt auch dabei, weitere Anbieter ein zu bauen, wie aktuell VBN (Bremen/Niedersachsen).

[mcm1957]

@TT-Tom sagte:

Da der Fahrplan-Adapter zur Zeit nicht gepflegt wird, habe ich mich entschieden einen eigenen zuschreiben.

Ähhmm
Worauf bezieht sich deine Aussage dass der Adapter nicht gepflegt wird?

Die letzte Release ist noch nicht mal ein Jahr alt. Und die Anzahl der offenen Issues ist ziemlich gernig. Hier zu behaupten dass etwas nicht gepflegt wird ist doch eher gewagt. Welches Issue hast du angelegt? Hast du den dev vesucht zu ereichen?

Nicht böse sei, aber ich bin mal gespannt wie lange du deinen Adapter im Monatsabstand aktualisiserts ...

In jedem Fall gebührt auch dir ein DANKE dass du Zeit aufwendest. Aber denk mal über deine Formulierungen und deine Einstellung zu freiwilliger Arbeit anderer nach.

[ticaki]

Ein Adapter der 6 Monate kaputt ist, ist nicht gepflegt

[mcm1957]

Ok - wenn es so ist.
Ist für mich aus den Issues nicht sofort ersichtlich.

Gehts um das Issue https://github.com/gaudes/ioBroker.fahrplan/issues/478 ?
Oder welches issue beshcreibt einen Totalausfall?

EDIT:
Wenn der Adapter wirklich nicht mehr funktioniert damnn sollte er aus den Repos raus. Nur dazu brauch ich greifbare Issues / Reklamationen / Bestätigungen. Meldungen eines Users dass seine Installation nicht funktionier sind für so einen Schritt zu dünn...

[ticaki]

@mcm1957 sagte:

EDIT:
Wenn der Adapter wirklich nicht mehr funktioniert damnn sollte er aus den Repos raus. Nur dazu brauch ich greifbare Issues / Reklamationen / Bestätigungen. Meldungen eines Users dass seine Installation nicht funktionier sind für so einen Schritt zu dünn...

Ich weiß nur davon weil ich öffters mit Tom rede und er darüber geklaggt hat:

https://github.com/gaudes/ioBroker.fahrplan/issues/478#issuecomment-3411125556

Da steht das es bei dem Nutzer nicht mehr geht. Da hat sich anscheiend die api geändert.

[mcm1957]

Ich hab dann mal ein TIMEOUT Issue erstellt.
https://github.com/gaudes/ioBroker.fahrplan/issues/543

Wenn kein Feedback kommt fliegt er aus den Repos.

Und damit nichts falsch rüber kommt:
Es ist voll OK einen zweiten Adapter zu entwickeln. inbesondere wenn es Probleme gibt.
Und DANKE an tt-tom für deine Arbeit

Es wäre aber auch sehr sinnvoll bei Verdacht dass ein Dev nicht mehr aktiv ist ein ganz klares Issue mit der Frage ob der Adapter noch gewartet wird zu verfassen. Es kann nie ausgeschlossen werden, dass ein Dev ein Issue in seiner Wichtigkeit auch falsch einschätzt.

Und es ist nach Abklärung mit Core auch jederzeit möglich verwaiste Adapter zu übernehmen sodass andere diese warten können. Damit ersparen sich User ggF eine Migration und eine spätere Zweigleisigkeit wird vermieden.

[TT-Tom]

Hi @mcm1957

ich will dem Entwickler nichts vorwerfen und weiss selber das Privat und Arbeit vor dem Hobby kommt. Würde auch gerne mehr in die Entwicklung stecken und kann es auch gut einschätzen, was da alles dran hängt.
ich hatte Februar 25 mein Issue angelegt https://github.com/gaudes/ioBroker.fahrplan/issues/443
und auch ein Lösungsvorschlag als PR unterbreitet, was dann irgendwann im Sande verlief. Da mein Fork funktioniert, nutzte ich diesen auch im Produktivsystem. Die andren offen Issues hatte dann in meinem Fork dann so gut es ging auch behoben und im Issue auch dokumentiert.

Irgendwann hatte ich mich entschieden selber ein Adapter zu schreiben und diesen auch hier an zu bieten.

Deine Arbeit hier und auch auf Telegramm schätze ich sehr, wobei es doch manchmal sehr direkt ist.

Ich werde den Adapter weiterentwickeln, über eine Aufnahme ins Repo können wir uns dann separat noch einmal verständigen.

[mcm1957]

@tt-tom

Wie schon im ersten post kurz erwähnt möchte ich hier nochmals ganz groß DANKE sagen dass du deine Zeit und dein Wissen für einen Adapter einsetzt.

Mir war auf Grund des Blicks auf das Repo in Bezug auf Issueanzahl und Releasedaten nicht klar, dass der Adapter ein echtes Problem hat und deine Bezeichnung als "nicht gepflegt" vollkommen richtig war bzw. ist. Ich hätte vor meiner Anmerkung genauer nachforschen sollen.

Sorry

Und danke für deinen Ersatz.

P.S. Bitte häng an den Latest PR noch den Object Dump an. Das steht zwar im ersten Antwortcommit (https://github.com/ioBroker/ioBroker.repositories/pull/5751#issuecomment-4188664955) dürfte aber untergegangen sein.
DANKE

[Oli]

@TT-Tom
Wollte gerade mal testen, bekomme aber folgende Fehlermeldungen im Log

public-transport.0
2026-04-23 18:36:49.938	error	Fehler bei der Abfrage der Station Forbidden. Fehlermeldung: %s

public-transport.0
2026-04-23 18:36:49.938	error	[stationReq] Fehler bei der Abfrage der Station 8000736. Fehlermeldung: Forbidden

public-transport.0
2026-04-23 18:36:49.866	warn	Verbindungen konnten nicht aktualisiert werden für: Bad Rappenau - Nürnberg Hbf

public-transport.0
2026-04-23 18:36:49.866	error	[journeyReq] Fehler bei der Abfrage der Verbindungen für Station 8000736 nach 8000284: Forbidden

public-transport.0
2026-04-23 18:36:49.787	warn	Abfahrten konnten nicht aktualisiert werden für: Bad Rappenau (8000736)

public-transport.0
2026-04-23 18:36:49.787	error	[depReq] Fehler bei der Abfrage der Abfahrten für Station 8000736: Forbidden

[TT-Tom]

@Oli

Bitte das komplette log vom Start des Adapter bis alle Abfragen durch sind.

[Oli]

@TT-Tom
ich hoffe, dass ist alles

v7.7.22

4
2
Log-Größe: 6.5 KB

public-transport.0
Zeit
debug
Nachricht

public-transport.0
2026-04-23 19:12:36.929	error	Fehler bei der Abfrage der Station Forbidden. Fehlermeldung: %s

public-transport.0
2026-04-23 19:12:36.929	error	[stationReq] Fehler bei der Abfrage der Station 8000736. Fehlermeldung: Forbidden

public-transport.0
2026-04-23 19:12:36.841	info	Infos für: Bad Rappenau (8000736) abfragen...

public-transport.0
2026-04-23 19:12:36.840	info	1 aktive Station(en) gefunden:

public-transport.0
2026-04-23 19:12:36.840	info	Warte auf die nächste Verbindungsabfrage in 5 Minuten...

public-transport.0
2026-04-23 19:12:36.840	info	Erste Verbindungsabfrage abgeschlossen: 0 erfolgreich, 1 fehlgeschlagen

public-transport.0
2026-04-23 19:12:36.840	warn	Verbindungen konnten nicht aktualisiert werden für: Bad Rappenau - Nürnberg Hbf

public-transport.0
2026-04-23 19:12:36.840	error	[journeyReq] Fehler bei der Abfrage der Verbindungen für Station 8000736 nach 8000284: Forbidden

public-transport.0
2026-04-23 19:12:36.766	info	Rufe Verbindungen ab für: Bad Rappenau - Nürnberg Hbf (journey_1776924771066)

public-transport.0
2026-04-23 19:12:36.766	info	- Bad Rappenau - Nürnberg Hbf (Von: Bad Rappenau, Nach: Nürnberg Hbf)

public-transport.0
2026-04-23 19:12:36.766	info	1 aktive Verbindung(en) gefunden:

public-transport.0
2026-04-23 19:12:36.765	info	Warte auf die nächste Abfrage in 5 Minuten...

public-transport.0
2026-04-23 19:12:36.765	info	Erste Abfrage abgeschlossen: 0 erfolgreich, 1 fehlgeschlagen

public-transport.0
2026-04-23 19:12:36.765	warn	Abfahrten konnten nicht aktualisiert werden für: Bad Rappenau (8000736)

public-transport.0
2026-04-23 19:12:36.765	error	[depReq] Fehler bei der Abfrage der Abfahrten für Station 8000736: Forbidden

public-transport.0
2026-04-23 19:12:33.346	info	Rufe Abfahrten ab für: Bad Rappenau (8000736)

public-transport.0
2026-04-23 19:12:33.345	info	- Bad Rappenau (ID: 8000736)

public-transport.0
2026-04-23 19:12:33.345	info	1 aktive Station(en) gefunden:

public-transport.0
2026-04-23 19:12:33.344	info	VendoService initialisiert mit ClientName: iobroker-public-transport

public-transport.0
2026-04-23 19:12:32.766	debug	[library] Load language de from custom

public-transport.0
2026-04-23 19:12:32.764	debug	[library] Load language de

public-transport.0
2026-04-23 19:12:32.753	info	starting. Version 0.2.0 (non-npm: tt-tom17/ioBroker.public-transport#6d445f87893d5a09379a865408c7d2b1290ff201) in C:/ioBroker/node_modules/iobroker.public-transport, node: v22.22.2, js-controller: 7.0.7

public-transport.0
2026-04-23 19:12:32.657	debug	States connected to redis: 127.0.0.1:9000

public-transport.0
2026-04-23 19:12:32.545	debug	States create User PubSub Client

public-transport.0
2026-04-23 19:12:32.544	debug	States create System PubSub Client

public-transport.0
2026-04-23 19:12:32.508	debug	Redis States: Use Redis connection: 127.0.0.1:9000

public-transport.0
2026-04-23 19:12:32.443	debug	Objects connected to redis: 127.0.0.1:9001

public-transport.0
2026-04-23 19:12:32.437	debug	Objects client initialize lua scripts

public-transport.0
2026-04-23 19:12:32.303	debug	Objects create User PubSub Client

public-transport.0
2026-04-23 19:12:32.302	debug	Objects create System PubSub Client

public-transport.0
2026-04-23 19:12:32.301	debug	Objects client ready ... initialize now

public-transport.0
2026-04-23 19:12:32.270	debug	Redis Objects: Use Redis connection: 127.0.0.1:9001

[TT-Tom]

@Oli

Okay schau ich mir an, was das Problem sein kann.

Du könntest in den Einstellung mal bei Clientname etwas eintragen. Irgend ein Wort

EDIT
Ich konnte es von der Ferne auch sehen. Aktuell ist nur die Vedo-Verbindung gestört. Muss mir das genauer ansehen wenn ich zu Hause bin.
Melde mich dann.

[TT-Tom]

@Oli

warum die DBnav Schnittstelle blockiert ist habe ich noch nicht rausgefunden. Ich habe intern auf die DB Schnittstelle umgestellt. Es kann sein, dass eventuell nicht alle Infos kommen.
Bitte testen. Version 0.2.1 ist auf NPM

[Oli]

@TT-Tom
scheint jetzt erstmal wieder zu funktionieren, bis jetzt habe ich noch nichts gefunden was fehlt

[Oli]

@TT-Tom
Sorry, habe doch noch was gefunden.

Es werden mehr Verbindungen und Abfahrten angelegt als angeben wurden.

[TT-Tom]

@Oli

Kann es sein das es vorher auf 5 stand?? Ich lösche keine Daten, setzte sie nur auf null, -1 oder false. Die Daten werden nur gelöscht, wenn die Verbindung/Abfahrt im Admin gelöscht wird.

Du kannst die Journeys selber mal löschen, sie werden bei der nächsten Abfrage wieder erstellt.
Dann sollten auch nur 3 da sein.

[Oli]

@TT-Tom
Instanz habe ich gestoppt, Alle Ordner gelöscht, Instanz neu gestartet und es sind wieder 5 Verbindungen angelegt worden

[TT-Tom]

@Oli
Okay, danke für den Test. Ich checke das heute Abend dann.

[TT-Tom]

@Oli

Version 0.2.2 (2026-04-25)

• (tt-tom17) fix countEntries for journeys

bitte testen, danke.

[Oli]

@TT-Tom
Folgendes ist mir bei der neuen Version aufgefallen:

1. Die Journeys scheinen jetzt zu passen, da werden so viele angelegt wie angegeben.
2. Beim Datenpunkt "countJourneys" ist die falsche Anzahl hinterlegt
3. Bei den Stations funktioniert es leider noch nicht, dort habe ich 10 hinterlegt