Hi @Jas and thanks!

Both of these are not supported. The concept of the module was to have a Sonos now playing... module with minimalist design hence:

• only vital information: title, artist, album (can be toggled), metadata: room, volume and track length (can be toggled)
• no album artwork
• show only rooms where music is playing, otherwise show nothing to avoid clutter

It would not be too hard to do all the above, but I don’t plan to do it anytime soon because of the concept.

That’s what I’m currently working on, a better layout to display the plane where:

• airline name can be toggled from the config
• aircraft type (if recognised) can be toggled from the config
• metadata can be toggled from the config

Also, the icon beside the altitude reflects the current vertical rate (stays horizontal if vertical rate is 0 or not defined)

@ytmytm Thanks for confirming this. I’ll take that into account when I’ll update the README.md

@ytmytm Cool, glad it works fine! I actually just realised that my last commit is not quite right regarding the connection retry if the TCP stream is closed. I’ll fix that for the merge in master.

Regarding the dependency issue, you are right, I missed the librtlsdr-dev dependency in the prerequisites list, I’ll add that (FYI, this is needed only for the rtlsdr mode). And I think you had to rebuild the module because it was missing when you executed npm i (It is certainly not something I had to do on my Pi)

I’ll clean this up and push to master, probably tomorrow though.

Finally, I’m also working on a new UI with better UX (I think), I’ll post screenshots when I can.

Alright @ytmytm got something working with the data exposed by dump1090.
This is available on the branch feature/network where also updated the README.md regarding the configuration: https://github.com/tbouron/MMM-FlightTracker/tree/feature/network. You will need to update the dependencies:

git fetch && git pull feature/network && npm i

I’m running this locally and seems to work quite well. However, can I ask you to test it and report back with any issues, or a thumbs up? I’ll push this “officially” when I’m sure it works for you :)

Hi @eliah. Can you try the version on the branch fix/group-scan and tell me how it goes ?

You would just need to go into the MMM-Sonos folder and do:

git fetch && git checkout fix/group-scan

Thanks :)

HI @ytmytm.

So I looked at this over the past week and it turns out to be more complicated than expected.

dump1090 does expose a raw stream of data but I could not use it as the data there is serialised from a C struct, which cannot be reconstructed from nodejs. I then looked at the SBS1 (BaseStation) stream to get the parsed data directly. This is a bit fiddly to make it work with the current codebase, and requires changes into npn dependencies I’m using.
However, this is the best alternative I could find so I’ll continue in that direction. Bear in mind that as I have to modify dependencies so this will take a bit of time before I can release something that works ok.

@eliah That’s interesting, it would suggest that the group IDs are not consistent (as groups are cached by IDs) which obviously shouldn’t happen. I’m also wondering if targeting a random device on every scan has any implications on this (but it shouldn’t, at least I cannot reproduce this on my own network)

Would it possible for you to test a different version? I would like to see how it can be mitigated.

Hi @eliah, thanks for your comment!
The module looking for groups regularly is by design: there is unfortunately no event when groups changes therefore they are pulled every 5 seconds. The listeners are set only when groups have changed.

I checked on my mirror and cannot see a difference of CPU usage with or without the module enabled. How “bad” is the CPU hog on yours?

Hum if we can get the data out of this then yes, I can look into this :)

I’ll look at dump1090 and see what I can do. Wanted to go back to the output design anyway so might be a nice feature to add.

I’ll let you know.