nerdculture.de is one of the many independent Mastodon servers you can use to participate in the fediverse.
Be excellent to each other, live humanism, no nazis, no hate speech. Not only for nerds, but the domain is somewhat cool. ;) No bots in general. Languages: DE, EN, FR, NL, ES, IT

Administered by:

Server stats:

1.2K
active users

#nodered

1 post1 participant0 posts today
Recently traveled interstate so my partner could see a concert and in doing so discovered that a band I love had come to Australia a couple of years ago and I had no idea. So this morning's #project was ensuring that never happens again using #nodered

Once a week, it'll pull Last.fm's events page for my city and a giant radius around Melbourne/Sydney/Canberra, then try to match events against all of the artists in my music server. Any new matches will be posted to fedi with my user tagged so I get a notification.
Continued thread

The issue was with nr-gotify node, it crashed the NodeRED when it couldn't reach my gotify server. Now I check if the gotify server is reachable before sending the message. Also added catch all node and used JSONata for first time to concat timestamp with the message.

Looking forward to use more of the JSONata to avoid writing JavaScript in the NodeRED, JS is weirder than usual here.

Parsing the Elite Dangerous Journal

I gave in and changed my event forwarding method in node-red for the Elite Dangerous Journal. This file is updated on various in-game events but in a way that makes it difficult to get new events only since last update. Another problem is that it’s not really a valid JSON file because it has one JSON per line but it’s not a valid JSON array. This is why it has to be parsed line by line and mashed together by event type (name) again to get the latest data for each event type per dump. Each event has it’s own timestamp by set by the game. The latest timestamp is now saved on the special flow const so node-red keeps the value in the “global” memory of the current flow:

msg.payload.event = "Journal";let newJournalTimestamp = flow.lastJournalTimestamp;Object.keys(msg.payload).forEach((key) => {  if (msg.payload[key].timestamp) {    const keyTimestamp = new Date(msg.payload[key].timestamp).getTime();    if (!flow.lastJournalTimestamp || flow.lastJournalTimestamp < keyTimestamp) {      // this entry is new - keep it. MULTIPLE events may have the      //  same timestamp so wait with reassigning so we don't skip      //  em or get the latest a 2nd time if nothing else changes.      // update the next latest timestamp if this is newer      if(!newJournalTimestamp || newJournalTimestamp < keyTimestamp) {        newJournalTimestamp = keyTimestamp;      }    } else {      // lastJournalTimestamp is newer, skip this      msg.payload[key] = null;    }  }});// make sure this is a valid date for the next timeflow.lastJournalTimestamp = newJournalTimestamp || new Date().getTime();// remove all nulled events from the payloadmsg.payload = Object.fromEntries(  Object.entries(msg.payload).filter(([_, p]) => p !== null));msg.payload.timestamp = new Date(flow.lastJournalTimestamp);return { payload: msg.payload };

So I do now keep track of the last read timestamp and reject every event that is older than the last read keeping the Journal dump smaller. This way I don’t have to try to keep track of the “latest” event to drag data from. Refuelling e.g. can happen from whopping 4 (or more) different events and it’s painful to compare all and check which one is the latest to keep track of the real current fuel levels for each tank.

Downside is I won’t get a full set of data for the current session any more if I have to reload my HUD app. This could be mitigated by using MQTT though where I could simply persist each event topic. That is already implemented and I can choose between SocketIO or MQTT in my app anyway.

https://beko.famkos.net/2025/03/29/parsing-the-elite-dangerous-journal/

OMG - What a ride... after tinkering and yelling at clouds @nocci was able to fix a lot of #NodeRED Code so my flow is way cleaner.

First pic is the whole mess noccis brain spit out yesterday and second shows his work after putting some "real" coding effort into this thing here. (now there are emojis)

(there are maybe some useful infos for you in the alt-text)

Over the past few days, I "channeled" my inner nerd into building an automated radiation detection system using open-source tools.

The device combines an ESP32 running
#ESPHome for sensor data collection, my #HomeAssistant for centralized smart home integration, and #NodeRED for automating hourly Fediverse updates via a bot account

@Radiation_SL (since this Geiger counter is located in northern Germany ( #Schleswig )

Technical Breakdown:

Sensor: Radiation D-v1.1 (CAJOE) - radiation detector

Connectivity: ESP32 transmits via Wi-Fi to Home Assistant

Case:
#3dPrinting the case (photo) - base is black and the lid is blue and shows the logo of "Fallout" (pc game/ TV series)

Automation: Node-RED flow formats data into ActivityPub messages

Decentralized Sharing: Posts include μSv/h readings

While this started as a hardware tinkering project, recent global events — nuclear rhetoric in conflict zones, aging power plants, and insufficient transparency in environmental monitoring — made me realize decentralized citizen science could play a crucial role.

Open-source tools eliminate single points of failure, and Fediverse integration ensures censorship-resistant data sharing.

Feel free to follow my bot account I mentioned above, if you are interested.

If I can find some time I will write a blogpost about the build process and link it in the bio / or just toot about it.

:boost:

Alright, first #NodeRED Question: I would like to have a timer that resets when additional messages go in. Idea is a that the light stays on for at least 90s, extended if additional movement is detected within the 90s delay period. I probably can code something with loops and re-evaluation of the delay value, but I much rather would want to know if there is a more elegant approach?