Offline
@sdetweil
Yeah, this module is kind of in my foster care.
I did not come up with the code; only made some tweaks and made it available.
There is not suspend or resume to been seen in the code.
But I will study the stuff you mentioned and will try to implement that.
Thx.
Hi,
I am currently adopting MMM-MPlayer to interact with MMM-pages.
Reason is that suspending the module does not suspend (stop) the stream, as it is an overlay.
As long as MMM-MPlayer is running, it will always display the stream.
From the config I can deduct the page index (3 in this case):
modules: [
["compliments"], // page 1
["MMM-YrThen"], // page 2
["calendar"], // page 3
["MMM-MPlayer"], // page 4
],
And I see that reflected in the log:
0|MagicMirror | [2025-01-18 16:13:55.383] [LOG] [MMM-MPlayer.js:65:15] Received MMM-pages NEW_PAGE 3
0|MagicMirror | [2025-01-18 16:13:55.804] [LOG] [module.js:189:7] compliments is suspended.
0|MagicMirror | [2025-01-18 16:13:55.835] [LOG] [module.js:189:7] calendar is suspended.
0|MagicMirror | [2025-01-18 16:13:55.917] [LOG] [module.js:189:7] MMM-YrThen is suspended.
0|MagicMirror | [2025-01-18 16:13:56.395] [LOG] [module.js:196:7] clock is resumed.
0|MagicMirror | [2025-01-18 16:13:56.439] [LOG] [module.js:196:7] MMM-MPlayer is resumed.
But I would need to see my module name in the payload (MMM-MPlayer in this case), to act on the correct page index.
Come to think of it, I also would need the keyword suspended or resumedin the payload, in order to know what to do.
Any thoughts on this ?
Best regards,
E.J.
@plainbroke
Yes, that makes sense.
Keyword: overlay.
I will reply in the MPlayer issue you opened for this, to not hijack this topic.
I tested this and indeed it does not seem to work (anymore).
For directionI used the station Id for the station adjacent to my station.
I will raise an issue for this.
@KristjanESPERANTO said in MMM-PublicTransportHafas: Service Temporarily Unavailable:
I just released version 3.0.1 to fix this 😀
At this moment I see an entry in the past with +0.5.
Also saw +0.6.
When turning on debug, I only see delay values of 0, 60 and null, so I wonder where the current 0.5 comes from.
The values for when and plannedWhen all have a difference of 0 or 1 minute.
It seems that it only affects the first entry in the list, which in my case is the first unreachable in the past.
And it does not really bother me, but it still is odd.
I personally do not use this, but are you sure about
direction: “682669”
?
Seems a bit off.
I did the update and it is looking much better now.
I reverted back to db (npm run query dbis working again).
Only one thing I noticed:
On display (last update 11:15)
11:08 +1.0333333333333334
11:28 +0
The 11:08 entry is in the past (maxUnreachableDepartures: 2,).
The +1.0333333333333334 is a bit too much :-)
$ cd ~/MagicMirror/modules/MMM-PublicTransportHafas
@p1lspeda said in MMM-PublicTransportHafas: Service Temporarily Unavailable:
Höfchen/Listmann
For you, try this:
$ npm run query rmv
Using hafas-client profile: rmv
Enter an address or station name: Höfchen/Listmann
Stops found for 'Höfchen/Listmann':
> Stop: MZ Höfchen/Listmann
ID: 3029051
Transport product(s): Bus
Config:
hafasProfile: "rmv",
stationID: "3029051",
stationName: "Höfchen/Listmann",
@othomys said in MMM-PublicTransportHafas: Service Temporarily Unavailable:
Georg-Schwarz-Str./Merseburger-Str.
For you I found this one:
$ npm run query insa
Enter an address or station name: Georg-Schwarz
Stops found for 'Georg-Schwarz':
> Stop: Leipzig, Georg-Schwarz-/Merseburger Str.
ID: 12555
Transport product(s): Tram, Bus
So your config will be:
hafasProfile: "insa",
stationID: "12555",
stationName: "Georg-Schwarz-Str./Merseburger-Str.",