All posts in Open source

And the first tests of Plex server (doing video transcodes) running on the new Mac Mni are in ;

https://forums.plex.tv/t/plex-media-server-running-on-apple-silicon-m1-chipset-i-e-new-mac-mini-macbook-etc/652252/50

And they sound absolutely amazing – read them.

ReJSON: Redis as a JSON Store
We’ve created ReJSON, a Redis module that provides native JSON capabilities. ReJSON should make any Redis user giddy with JSON joy.

I have used Redis for many years – both as a database cache and as a super fast in-memory database. But it has not evolved a lot for  a long time.

But this seems to have changed – RedisLabs (the commercial arm of Redis) has released a number of opensource/commercial modules for Redis.

The first one I have looked at is RedisJSON – as I saw the potential to upload a whole Azure Cosmos database for one of my projects into Redis, while improving speed and drastically lowering costs. (Cosmos is well known for being expensive to run.

So I’m currently writing a POC to test out my theories – onwards and upwards.

We have a flat with very thick walls – giving us problems with wireless connections. We have a mesh network (TP-Link Deco P7’s) with Powerline backhaul. The theory was that when wireless signals could not go through the walls we would fall back to running the network over the mains cables between mesh access points.

The real challenge comes from the difficulty in finding intermittent problems on the network, and the series lack of any decent admin functions on the P7’s.

The mash network has 6 nodes, where the first one is connected to main router with a Ethernet cable. The rest of the mesh is using Powerline or the wireless network between them dynamically. Unfortunately there is no real way to know how each node is communicating with the other nodes.

I’ve tried most things I could think of and feel we are in a good place with the connectivity at the moment, with the exception of my wife’s studio. And kit in the room occasionally has problems.

In the end I installed one of the oldest and first monitoring systems I ever used – Smokeping. And it’s still one of the few latency and network error measurement and login tools I can find. But it’s a very difficult install under OsX – even though I had done it before. So this time I went modern, and downloaded a pre-made setup in a Docker container – and started configuring the monitoring tools.

It now looks like this

NewImage

And look at the packet loss line – 10% packet loss on average. And it was even worse for the printer :

NewImage

Average packet loss of 93% – its a wonder it ever works! But both these devices are connected to the same Access point – the Printer using a Ethernet cable – and the AppleTV using wireless.

So now I have a starting point – the cable between the access point and the printer is now the next thing to be inspected – but that’s for another day.

So SmokePing works very well for this type of investigation.

Btw. Here is the page for all access points :

NewImage

Just finished the brew – and here are a few post-brew notes.

– The BrewDao brewing page enclosed with the pack is a bit lacking in details, so I used the standard Grainfather calculations for how much water to add to the sparge. This turned out to be wrong, as this should be 25 Litres, not 28 Litres as assumed in the Grainfather calculations.

– On the positive side using a keg hopper to keep the hop pellets in made cleaning a lot easier, and the finished product a lot clearer.

It’s now all fermenting – so in a couple of weeks I can report back on the results.

Todays brew :

NewImage

Never brewed this particular one before – and as it includes dry hopping it will be the first time I can do this with all the hops in my hopping container, hoping to make the finished product slightly clearer.

Santa brought me the ingredients for a “Dead Pony Club” Brewdog beer – so tomorrow will probably be a good day to brew.

Brewdog releasing their recipes as open source is definitely one of the best things to happen to us amateur home brewers over the last few years.

NewImage

2 Weeks ago I spoke at a Data Ninjas meet up in Bristol about AI.

Excellent meet up where I met a lot of very nice people.

IMG 4680

As can be seen from the graph the new thermostat seems to work as it should. And the controlling software (FHEM) now runs off a Raspberry Pi.

NewImage

The red line is the set point temperature

The violet (?) line is how many percent the radiator actuator is open.

The green line is the room temperature as measured by the thermostat.

Btw. this is from today (Sunday) – and it was down to freezing last night.

One of our thermostats stopped working properly – and then I found out that they are not being produced anymore, so I had to buy a set of MaX! thermostats/actuators, cube.

And these are now installed in the living room and on the home automation system :

NewImage

I’ve just built my first radiation counter for a Raspberry Pi – and intend to add this to the house monitoring system. At the moment it’s warming up – I will have further information soon.

 

But while I was waiting for it to warm up I found the following on another Radiation counter I may try to get hold of as well :

 

PiGI Module

PiGI V1.0 Prototype Board

The Raspberry Pi is a perfect platform to be a cheap but very versatile geiger counter. It can be connected to a TV/Monitor to display a nice graphical interface, it can play the nostalgic tak, tak, taktaktak sound via audio output and it can also serve as an autonomous geiger counter sensor node (even solar powered) collecting and sharing real-time and historic data. All you need is:

  • A Raspberry Pi
  • PiGI Module
  • Geiger-Müller Tube

The PiGI is designed & built as a simple open-source plug and play module for the Raspberry Pi to transform it into a cheap and hackable multi purpose geiger counter. It generates the necessary high voltage (up to 1000V) the GM tubes require to operate (typically 400-600V for beta/gamma GMTs).

Some pancake sensors (mostly used for alpha radiation) require an even higher voltage, theoretically the circuit should cover it. However, that’s untested, only a LND712 (new, see picture) and two old Phillips tubes (Frieseke&Hoepfner FHZ74/76) could be tested, due to limited prototyping resources.

For every impulse the geiger tube registers the PiGI pulls a GPIO Pin of the Pi to ground (falling edge detection). On the Pi runs just a little daemon called counterd which waits for an interrupt to register the count and notify the display/audio/data-storage/network handler. That’s why it can also easily be connected to any other embedded/micro controller system like:

  • Arduinos
  • ATMegas
  • PICs
  • Spark-Cores
  • Other embedded Linux ARM/MIPS systems with GPIO Inputs (Netus G20 etc.)

HOWTOs can/will be provided, drop a comment if you need one for connections/pull-up configuration.

 
12349Next