Shelly Plus 1 GPIO

I am quite impressed with Shelly stuff anyway, but the new "Plus" range has allowed some interesting developments - as they use ESP32, which is the processor I use for my access and alarm system.

This has meant I am able to add bits to the alarm system much more simply than using my custom boards - anywhere I need just an input and/or just an output, for £15.99 I have a device that does the job. As an output it is a dry contact relay, and can be powered from 12V DC, or 24V-240V DC, or 110V-240V AC, so very flexible. Working with alarm system 12V DC or 24V DC is easy. Only catch is it should be 12V not 13.8V so a regulator may be handle, but it seems to cope without, so far.

The input is run at "live" so for mains working needs a proper switch rated for mains such as a light switch (or one of the nice retractive switches). But working on alarm system 12V, a simple contact like a reed switch, or connection to a PIR is simple.

Obviously there are plenty of uses for the alarm system that needs more than one input or one output, but this is pretty useful. I even have one electrically locked door that is just using one for the lock and door open inputs as it is a door that does not need a fob, just needs to be locked when alarm armed, and detect door open as an alarm input ("access", causing alarm if armed).

My new EL560 locks on the house are great as no need for break glass or exit button as they open with the inside handle. But if you have any doors you keep unlocked during the day, you need a way to lock the doors at night. And that needs a button. Well, a Shelly Plus 1 is ideal. The light shows the doors have been locked.

I have also worked out the GPIO:-

• GPIO0: Output for small LED (hard to see through case).
• GPIO4: Input for SW signal (external switch) but needs configuring as pull down.
• GPIO25: Input for small blue button on the case, but needs configuring as pull up.
• GPIO26: Output to work relay.

There are also 6 external connection pins for programming (WARNING: THESE CAN BE LIVE):

• GND
• GPIO0
• EN
• 3V3
• GPIO3 RX to shelly
• GPIO1 TX from shelly
• GPIO16

These can easily be flashed with tasmota too, use the ESP32 solo build. Note I cover two extra GPIO than the usual tasmota config (GPIO0, GPIO25).

A bit more on air-con

I have been tweaking the air-con even more.

The control I have, basically, is to set the target temperature. I can set higher than now, and lower than now, and so make it turn on or off. But sensibly the air-con has controls. It does not run the compressor exactly to match what I say, it turns on for a minimum time, and there are also sorts of laggy effects for the temperature to react. Once compressor was on it stays cool a while and then fan blows cool for a while.

But it is getting silly.

For the last hour or so, even more so. This is not like ±0.1℃, it is more like ±0.05℃.

It is really good. But I was thinking, is this just that it is a cold day in Wales and the temperature happens to be settling where I want? At 22℃?

Well no, it is not that, looking at the power usage I see that it is turning on and off the compressor to work the temperature.

What I did was make it predict on a trend the next 2 minutes and turn on/off (set high/low target) based on that. And it was surprisingly good. This is the power usage showing it is fine tuning it to manage that. It is controlling the temperature to well within ±0.1℃ with no problem.

Wow.

P.S. Just to clarify (as someone asked), this is not switching between heating and cooling (which would use more power), this is turning cooling on and off. It will switch to heating, but only after quite a while of temperature not coming back within range when off - and that can happen on some days in spring/autumn, but usually only once (each way) in the day. It also does automatic fan control.

Starlink

Finally got one for testing, so first experiences.

1. Ordering was simple, but the site is one of these "slick modern sites" that are a pain to find any proper information - very easy to order - not so easy to realise an Ethernet adapter is separate. I have finally ordered one now.

2. Arrived very quickly (ordered 1st June, arrived 6th June, Jubilee in the middle).

3. Very very confusing re "account". The pages all have "sign in". I cannot find any "create account". What I did not know is that when I ordered by simply clicking "apple pay" and double clicking my phone (yes, very slick), is that this "created" an account using the apple pay email address. Once I worked that out I could use the "locked out" link to get a password. They could make that a lot clearer.

4. The instructions are simple, you plug it in and point at the sky and connect to wifi - it makes you then create an SSID/password, but then it works - Internet, several MB/s of it. NAT / IPv4, but yes, works. I now need to find somewhere vaguely sensible to put it - away from trees - may need a pole on the wall.

Of course the next steps are to get the Ethernet adaptor, and start working with FireBrick, see if I can get an IPv6 address; see if L2TP/IPsec/etc tunnels work over it; etc, etc... So R&D to do.

P.S. LOL, you can get to RT.com via Starlink :-)

New air-con, part 6

Well, well, well... I am impressed with 4 Seasons. They have only gone and sorted it.

This is the huge difference between this install and the previous Mitsubishi install from a different company. The customer service to get to the bottom of the problem and fix things.

Firstly, they did discuss this "anti-freeze" mode with Daikin, and whilst we all agreed that turning the fan down was silly, their point, which is very valid, is that it should not be happening at all. The refrigerant should not be getting so cold in the first place - this is a fault condition. That is what needs fixing.

Naturally I leapt to the conclusion that the issue was air-flow. But I was wrong. It seems the advice from Daikin at this point was right - they said to check the refrigerant. Well, pressures had been checked several times. But they suggested there was too little refrigerant. Indeed they suggested (counter intuitively) that we would see these lower temperatures if there was not enough refrigerant. That seems crazy, obviously.

Well, the installer, and I, were rather baffled, but the only thing that basically makes sense is that the system is (over) compensating for the lack of refrigerant, and that is how it ends up colder. And, of course, at the same time, it is unable to carry the heat away properly, so does not work as well.

The symptoms were pretty simple, when cooling, the refrigerant quickly goes down to as low as -10C, which it manages for a few minutes, and then the anti-freeze mode kicks in, and everything stops for 10 minutes, and overall things are not working well.

Now, the refrigerant is settling around 5C with no problem, and cool air is coming out, and the room is quickly cooling. It is not going negative at all, not even getting below 4C. It varies, and I have seen 5C to 8C, but that is "sane".

So what did we fix?

The fix was to completely drain down the system and refill it - simple as that. The big clue was that only 0.9kg of R32 came out. It should have had around 2.5kg. So he emptied, vac'd, and refilled. What I had not appreciated is that these systems come pre-filled for installation, so it seems that somehow it must have come without the right amount - some must have leaked in transit (not good). But the only real test he can do is pressures, and they were fine, so no clue that there was not the required amount of R32.

I'll add some graphs once we have a couple of days running to confirm. But I am sat here on a warm sunny day in a nice cool office. To say that I am over the moon is putting it mildly.

Side effects

A small side effect is that my Daikin wifi modules have way more monitoring and reporting and graphing now. I did loads of work to try and find what was actually happening, turning in to a seriously useful tool.

Next job is the new controller to work with it for when people want manual control but doing a better job than the normal Daikin controller.

Another small side effect is that my previous very tight temp control is now a little less tight as the effect of cooling (or heating) is much more and continues longer, so some level of predictive processing may be needed to manage tighter temp control. Should be pretty easy.

New air-con, part 5

After the fiasco of the previous air-con install, I was pleased with the new one, as you can see, and especially that I can make my WiFi controllers.

However, this month, as we have got warmer, I have run in to an issue. It was gradual, kicking in some afternoons. Initially it was something that fooled my temperature control, causing it to flip to heating and back to cooling...

I made the controller a bit more reactive, and fixed the flipping to heating, which was good, but still, in the afternoons, things were not right.

Will all this, over night was OK, mostly, but not always. After a while I realised the clue was in the power traces. Basically, after a while the unit switches in to a mode where it cycles, around 11 minutes on, and 11 minutes off, and a low fan when off too.

This is not enough to keep my office cool, and as we go on, it is getting worse and worse. It always starts the day OK for some minutes, but can go in to this mode right away after that.

This is crazy. I tried all sorts. I thought maybe it is the "econo" mode, which apparent limits cooling when below a certain temperature. I even fudged the temperature (replacing thermistor with a resistor) to test this, but no joy.

After a lot of testing for a couple of weeks, I have found it. It is an "anti freeze" mode. This is what they say (when you know what to google). Needless to say that Daikin support did not work this out for us.

What is especially annoying is that when it is pending 10 minutes with "thermostat off", it also puts the fan in what is shows as "LL" mode, i.e. slower than "L". Well, if it want to avoid the coil freezing you would think it should keep the fan at "H", but that is not what happens.

So now we know what it is, well what can I do?

For a start, I can try and pre-empt the anti-freeze logic, but that does not really solve the problem of why it is freezing the first place. It would have helped a lot if Daikin could have simply said "that looks like anti-freeze kicking in" when asked. Indeed, a fault/indicator on the controller or controller app would have helped so we knew the problem.

Even so, a way better outcome than previous air-con install, and some hope it will be "just working" soon.

Update: Clearly air-flow is the issue, but by preempting the anti-freeze I can keep it on full fan more and so have a slightly improved performance for now.

Part 6

Not using solder paste?

I made the mistake of ordering a board and not ordering the solder paste stencil.

So what to do - well, not a complex board, I tinned the pads and applied some flux as it is a bit sticky...

Then I applied the components. Now this is where I wish I had applied less solder to make it flatter as they did not stay put very well.

Getting flux on the tweezers was also an issue, so lots of cleaning.

Then I cooked in the oven the same as if I had solder paste.

To my utter amazement, it worked perfectly. I did put in a sonic cleaner, which did not help much in cleaning it up...

However, a nylon brush and some IPA, and bingo..

But the damn board works!

So there you have it - an option when you have no stencil!

DHCPv6

First off, an apology! FireBrick and A&A have been pioneers in making IPv6 work in practice in the UK. The current FireBrick operating system has been designed with IPv6 from the start, and not as an afterthought. This means that at every stage the notion of an IP address comes with the notion of "which sort of IP address". We are proud of that. But we have been lax in one notable area - DHCPv6. Sorry.

The problem is that IPv6 has a mechanism, SLAAC, which assigns an IP address on Ethernet. It is very simple, and works. The router sends out some details (which can include DNS servers, etc, as well), and allows devices to pick an address. With 64 bits of local address, this is easy to do in a way that avoids any collisions. Indeed, devices often pick lots of addresses, cycling them quickly, to hide how many devices you have on a subnet, etc. (privacy addressing). It works well, and in the UK it was pretty much the only thing being used.

DHCPv6 is a "stateful" way to manage addresses, and like DHCP (for IPv4) it has a lot of options. Thankfully IPv4 DCHP has been around a long time, and the sane options to implement are clear. The FireBrick IPv4 DHCP server is actually pretty flexible and powerful and works well.

But DHPCv6 is newer, and has a lot of options. One of the big ones is "prefix delegation" - telling a device it has one or more blocks of IP addresses to use on its interfaces to give out to devices it has connected. This is just one of the complications for a DHCPv6 server on Ethernet - it has to consider not only allocating and tracking an IP address, but a block of IP addresses and routing. As a client we also have to consider if we want to ask for a block of IP addresses and what interfaces we can use to assign those IP addresses.

We do this already, but we only do it for the LNS/PPPoE (broadband) side of things. We work as a server when operating as an LNS, linking to RADIUS and routing. We work as a client when PPPoE, allocating a dynamic block of prefix delegated IPs to the LAN interface. So we have a lot of the tools already.

Until now we did have an option on our router announcements on IPv6 over Ethernet to allow a DHCPv6 server, and even an option for that to be the FireBrick itself. The idea was the FireBrick would issue an address the same as SLAAC. This was specifically to allow for devices that only worked using DHCPv6. But we really did not find any such devices. Devices (like the FireBrick itself) that only handle SLAAC are actually more common from what we can see.

But the time has come for DHCPv6. And there will be several alpha releases around this. We need to take careful steps to integrate the code which currently only works for LNS and PPPoE to be used for Ethernet. We need to decide on the config for this, and the options we offer. This will not be simple.

So, watch this space. It will take a while as we are working hard on the new 10G FB9000 router right now, but we are starting. We already have an alpha which does a consistent simple IPv6 address allocation over DHCPv6 on Ethernet (a hash based address to avoid giving out the MAC). We hope next to have DHCPv6 client over Ethernet and then DHCPv6 client prefix delegation. The server side will be a lot more work considering the config, and how much we link with IPv4 config, so bear with us.