Energie: Mehr als 33.000 neue Balkonkraftwerke in Bayern
https://www.zeit.de/news/2025-07/02/mehr-als-33-000-neue-balkonkraftwerke-in-bayern?utm_source=flipboard&utm_medium=activitypub
Gepostet in BY - Nachrichten aus Bayern @by-nachrichten-aus-bayern-ZEITONLINE
Energie: Mehr Balkonkraftwerke - Mittelfeldplatz im Ländervergleich
https://www.zeit.de/news/2025-07/02/mehr-balkonkraftwerke-mittelfeldplatz-im-laendervergleich?utm_source=flipboard&utm_medium=activitypub
Gepostet in HE - Nachrichten aus Hessen @he-nachrichten-aus-hessen-ZEITONLINE
It's running from onboard battery now! I'm not going to button it all the way back up until after some testing, but it works. I'm letting it run a Mastodon mode which will auto-update every ten minutes, with a GoPro on time lapse to see just how long it lasts. This project is getting *very* close to done.
...unless I decide to add a power switch.
...and I still need to make the video.
Sometimes, I receive questions which leave both me, and the person asking, bamboozled.
> Your website loads so quickly! What CDN do you use?
There is no CDN. It is just really small and simple, mostly text.
> Sure, but is that Cloudflare, or...?
None. It is a tiny website, just a few kilobytes per page, on a tiny server, at my home, connected to the Internet via my ISP, Andrews & Arnold.
> But are you / they in the cloud?
No. The webserver is in Newbury, in my garage.
> Neil, please can you pass my questions to your technical person? I don't think you understand, your website cannot be in your home. It must be in the cloud or have a CDN.
*Neil puts on glasses and false nose and moustache*
Habe gestern mit meiner großen Stadt Land Fluss gespielt. Dann sagt sie zu mir aus voller Überzeugung Ungarn nennt man doch Holland. Ich war schockiert und hab gefragt wie kommst du darauf. Dann sagt sie. "Ich hab mit einer Freundin gespielt und als uns kein Land mit H eingefallen ist haben wir gegooglet."
Ich hab das dann auch gemacht. Seht selbst.
When a train crosses back and forth there's clearly a different message that's sent, with UDP data size of 82 bytes.
At the end of this packet is "John Doe" followed by two null bytes. John Doe was who sent the train.
The first six bytes of the message are non-null. I suspect they will relate to the types of train carriages and maybe directionality and speed of the train.
But it's too soon to understand the messages. I have to send more trains to figure this out! 😁
In the screenshot you can also see there are some larger packets with payload size of 1394 bytes.
I suspect these may be related with the map configuration, since when you right click on the tunnel you get the track configuration on all maps and the train positions (which is really cool!). Actually, you also get the Post Office and Depot locations.
It seems normally packets with that size are sent in pairs. Sometimes from John to Sarah, sometimes the other way around. Maybe they relate to two map layers or something.
For reference, the playing area is of 48 x 48 tiles. 48x48 = 2304. 2304/2 = 1152 < 1394. So each each byte probably would have info for at least 2 tiles (if that's what this message contains at all).
I've bounced the same train back and forth (with a blue signal on John's end, closed Depot on Sarah's) a number of times at full speed, them half. See the setup in the picture.
I've used tshark to get the UDP payloads for each packet send from John to Sarah so that I can then see commonalities/differences between the packets.
tshark -T fields -e udp.payload -r /tmp/loco_sarah.pcap 'len(udp.payload)==82 and ip.src==192.168.1.241'
Every two packets has the same contents, except for a single byte that seems to increment (by two) every time the train is sent through the Tunnel again.
My first definite conclusion from this experiment is that the train speed is not sent in this 82-byte message. Because there's no change in it from sending at full vs half speed.
It seems that "John Doe x" is the name of the train, as possible to see on the interface.
After a few experiments I think the 82-byte packet does not contain carriage, speed and direction info at all. The only thing I'm sure it contains is the train's name.
It looks to me most of the bytes may contain uninitialised memory, so not meaningful data. I think so because I see the exact same train potentially start with many null bytes but some other times have data there, without any clear pattern.
The screenshot shows some division of the message with notes on what each part may be (probably wrong/imprecise).
It's clear I need to look at other messages next.
I should also mention I tried to send some of these messages to Sarah's machine, but no train appeared there. The server replies with something though.
As I now think this message is not what actually "sends" the train that's reason enough for no train to appear. But another reason may be that perhaps the server checks if the player IP is the expected one (and I'm sending packets from a third IP). Curious to find later if that's the case or not.
A problem I have is that since it's #Virtualbox saving the capture, I don't have it loaded in real time in #Wireshark. It would speed things up to see the captured packets and game side by side in real time...
Ah! Solved it!
With the following I create a virtual interface that gets new packets as they are written to the file. File must be read from the start, so that #Wireshark considers it a valid pcap file, hence the -c +0.
wireshark -k -i <(tail -f -c +0 /tmp/loco_sarah.pcap)
I've figured out the 1394-byte message!
It's actually part of a set of three messages: two 1394-byte long and one 335.
As I suspected, those 1394 transmit map information. But the full map information is split across those 3 packets. Maybe because they're UDP and LEGO didn't want the packet to be too long not to cause problems..?
These 3 messages are sent every time the Toybox is closed by a player.
To figure out what the messages were and their structure, first I made Sarah destroy the full map with the bomb in the Toybox (the Blue Tunnel remains there though). Then I started adding elements such one track and one tile to coordinates (0,0), then the full first row, then the final row. Then the whole map.
Conclusions:
PS: I had written previously that the map was 48 by 48 tiles, which is wrong.
Tracks are represented by 0x05. Grey tiles by 0x07. Those are the only ones I checked for now.
A Blue Tunnel is a 3 by 3 square filled with 0x05.
The screenshot shows what I've been able to figure out of the messages so far. I know there are some fixed bytes that seen to vary with the message number; some counters; there's the DirectPlay ID of the player who closed the Toybox; and of course the tile info.
But there are two chunks of bytes I have no idea about so far.
I really hope there are no checksums involved here 
Just noticed that now right clicking on the Tunnel from John's side shows Sarah's map as all grey.
For a moment I thought this could mean Sarah was offline. Nope! It's a representation of Sarah's fully grey-tiled map! So it seems this view may actually show not only tracks and related buildings, but an overall view of what the other player has placed in the map!
I'm continuing to figure out the protocol for sending trains. I'm currently pretty sure about some parts of the message, such as train direction, speed, locomotive type... Now I'm trying to understand how carriages are specified.
Regarding speed, I thought I had that field pretty much figured out. I thought a specific byte at 0x01 meant half speed and 0x04 mean full speed (never mind the weird jump...). But then I saw a train at full speed with value 0x02. I thought "oh well, must not be the speed after all". But then... I realised steam locomotives move slower at full speed than "silver" locomotives!
The view below shows a race between a team locomotive and silver locomotive trains. Silver wins, which matches 0x04 vs 0x02 speeds 😁
I figured out a few more things in the "send train" messages. But I can't figure it out fully. Nor, more disappointingly, can I manage to send trains.
The image shows what I know about the messages involved in sending a train.
And here are some conclusions:
To figure out what I did of the messages, I sent quite a few trains with varying locomotive and carriage types, and among multiple players and their configurations on the overall map.
The first screenshot below shows two of the configurations I used. The remaining screenshots show what the map actually looked like for each of the three players.
It's cool that depending on the zone of the map LOCO creates for you a track that connects the tunnels in a way that make sense for your location on the map. So those three screenshots are from what LOCO did, it wasn't me creating those track configs.
Some bytes seems to be the locomotive or carriage types. I've taken note of the hex string for each type as I've understood it.
DIE ZEIT
Matthew Dockrey
Pavel Machek
Neil Brown
Callisto
Heiko Does
LaF0rge
✧✦Catherine✦✧
Gonçalo Ribeiro0418. yellow loco
0618. silver loco
0818. steam loco
6618. silver carriage
6818. blue carriage
6a18. green carriage
6c18. yellow carriage
6e18. gas carriage
7018. mail carriage
There's a one byte that seems to indicate the direction of travel between the maps of two players, as follows:
00 ↑
0e ←
5a →
b4 ↓
When a player right-clicks on a tunnel a window shows the overall look of each player's map and how they are connected. It also shows the location for players' trains.
When this view is opened there are two 14 and 24-byte messages that are exchanged between players every second. One of these clearly contains the coordinates for trains. I only did a cursory analysis of it though to verify the hypothesis.
One interesting thing I found is that the messages sent when the Toybox is closed (that contain map information) don't have information on the exact map elements as I thought before.
I tried placing different elements on the map to get a notion of their codes and found out only four below values (this wasn't an exhaustive test though).
From what I could understand each byte is just transmitting which colour should be shown on the map overview for each tile of the map. I've found the following approximate meanings for each.
0x02: nature (green)
0x03: buildings (brown)
0x05: track (black)
0x07: pavements (grey)
The images below show a screenshot of a map (from one LEGO LOCO's presets, which brings memories) and its representation when right-clicking a blue tunnel.
Regarding being unable to send trains... It's a shame I'm unable to send trains because that would allow me to run experiments and understand the protocol much faster... And probably find some weird stuff/quirks.
As a test I've tried to essentially replay trains that I captured in pcaps. I did this in multiple ways.
My basic attempt was just to send messages with perl + #ncat as follows. I sent the three main messages by putting these commands in script with a sleep of a few milliseconds between them.
perl -e 'print pack("H*", $ARGV[0])' <hex string> | ncat -vu 192.168.1.242 31415
As that didn't work I tried changing the message counter, the train ID, etc. I thought maybe the game checks for duplicate messages or something based on the counters, which would mean the replay of an exact previous message would fail.
Next, I had the theory that maybe the game was checking the source IP address of the packet to see it if matched the expected player's address based on the DirectPlay protocol phase.
So I added the following #iptables rule such that any traffic coming from the host towards Sarah's VM (192.168.1.242) would appear as if had come from James' VM (192.168.1.243).
iptables -t nat -A POSTROUTING -p udp -s <my ip> -d 192.168.1.242 -j SNAT --to-source 192.168.1.243
In the packet captures I could see that the source IP changed as intended and Sarah's game responded to these messages, but no trains were produced.
Lastly, I thought maybe I was missing something... maybe there was another message other than those three main ones which had to be send to say "okay, that's it, that' the train right there in the previous packets!"
So I tried to replay a set of packets exactly as I captured them. To do this I filtered a set of James's packets, saved a pcap with them and used #tcpreplay to send them.
Again... no train.
Worth to consider though that with this test I used the correct source address for James (with iptables rule), and sent exact packets seen before, so any counters or similar that may need incrementing were left as is, which may be problem.
In short, I can say for now I'm beat. (Or that at least I'm not willing to invest more time in this right now.)
I started this thread with the idea to explore a bit how things worked. I thought maybe it was a simple protocol which I could figure out and send some trains! Turns out it's not that simple.
But still, I found a few interesting things both in terms of gameplay and on how things work in the background to support that experience. So I still consider this a success in that regard.
Ah, I forgot to mention that I wrote a small diff tool to try to figure what was fixed on the messages of a specific train and what wasn't. This is in part because I suspect/suspected that there are extensive regions in a message that are/may be uninitialised.
What this differ tool does is I can feed it hex string from the same type of message and it will check for each nibble which values were found among the messages. Then it represents that by writing lines of hex and spaces where each column represents all the variations found for that nibble.
The screenshot below shows an output example, with a section of a message. Where there's only one value per column it means those nibbles were always the same, so they are probably constant for at least this type of train. There's an highlighted part which is something I had already the theory was constant and this output agreed with.
You'll notice many nibbles with value 0x2. This was purposely caused by filling Sarah's map with "nature" (0x2) elements such that any uninitialised memory had a higher probability of being filled with a recognisable pattern.
I suspect many of the parts in this section of the message (as an example) are uninitialised. But maybe if that was the case I'd have even more nibble values. So I don't really know...
Andrew Borley