New door entry and alarm system

I am thinking of the next generation of my SolarSystem alarm system.

It started as RS485, a slot in replacement for a Galaxy system using the same external devices, and running on a Raspberry Pi with USB RS485 adaptors. It worked quite well.

The next generation used ESP8266, then ESP32 based WiFi connected devices. This works well.

Next generation

I am now planning to get rid of the Raspberry Pi and RS485 completely. The idea is the ESP32 modules work together over a mesh WiFi. Yes, one of them would connect to a conventional WiFi access point, but they can work without that - off 12V battery backup if needed, with no "controller" as such.

This is not that complex - devices need to know what inputs and outputs link to what areas and states in the system, and broadcast information to allow every unit to know when alarm armed, or triggered, etc. Using secure AES encrypted DESFire key fobs on door controllers the alarm can be set and unset.

There would still be a "controller" to configure the system, program fobs, record logs, and so on. But this could be a cloud based service. Some of you know my love of cloud based services (not), and as this is all open source it would allow the cloud service to be run locally. But the server is not a "live" part of the system - it allows config, and so on - via a simple web page. Obviously communications would then be secure to the server.

This makes everything simpler to set up as you just need a local WiFI internet access.

To make it work I now have designs (and several prototype boards and cases) for key components:

• Door controller module and NFC reader (can be used as 6 input 1 output module)
• Bell box module (also usable as a 2 input 4 output module)
• General purpose I/O (5 GPIO with ADC if needed)
• Keypad module (fits in galaxy keypad and talks RS485 to it locally)

The nice thing is that just one of these, eg door control, can be set up to talk to local WiFi/NAT and connect to a cloud service allowing configuration of an access system. But you can then add other modules, and set up a whole alarm system if you want. The key fobs have access controls such as which doors, and times of day and days of week that are allowed.

More serious work needed

The issue is that I need to do quite a lot to complete the design and coding for this - not just in the modules, but the controller system and database back end. This is all pure R&D work at present with no concrete customers for the system (though we have had some interest), which can make it a bit hard getting the motivation - but a real customer would also help ensure we are steering the project in the right direction.

Bootstrapping security

One of the design challenges is bootstrapping the security of key fobs and controllers. They need AES keys, and these need to be secure, and need to get in to devices and fobs.

In simple practical terms, you can just buy fobs from the likes of Amazon, and then use one one of the NFC modules - e.g. one of the doors - to program the fob. Similarly you can make ESP32 modules, or use off the shelf modules like nodemcu and flash the code.

But you have to be very sure that this is actually being done by someone authorised to program fobs. Even then, if someone wanted to, they could capture that initial config and get the AES key used. Once the AES key is know the system for a whole site can be compromised.

Once the fob is programmed, any capture of the communications does not help you, but the initial set up of a fob is inherently insecure - this is the bootstrap problem - it has to be insecure as the fob is blank and it has to get the keys - so someone can "pretend to be a blank fob" and get the keys in the same way.

You have the same issue with end devices and a cloud system - you have to be sure the device is the device you think it is. If someone can get a fake device on a system it can get keys. So the devices need a secure client identity too.

I suspect the answer is simple - design the system so that the controller will only do initial config of devices and fobs locally (e.g. USB connected). The controller then sends out the devices and fobs pre-set for the site. Of course this means for a cloud based service the service operator provides the devices and fobs - which may make it more commercially viable to operate a cloud service.

Security

Of course any system has to consider security - the AES/DESFire fobs are massively more secure than 125kHz fobs used by Galaxy Max readers. The WiFi is a bit of a trade off: It is way more secure using WIFi and TLS than RS485 (Galaxy modules can have messages inserted on the bus without it noticing!). It is possible to disrupt (just as cutting an RS485 bus is, which is exposed on outside of building if using Max readers), but like RS485 it would trigger an alarm. At the end of the day you have to be more secure than breaking a window.

Never quite finished?!

The good news is I now have the "proper" PCBs for my door controller and NFC reader...

I have to say they look good - proper boards, and using solder paste and oven means a very professional result.

PCB Train do a nice job, but these were on a three week lead time. Both boards work. However, in the three weeks since I ordered I have made a few design changes.

The door controller changes are very minor - instead of 3 inputs with 3 GND on the 6 pin connector I have all 6 pins connected to GPIO, where you drive some pins to GND if you want. This allows a lot more options if needed, etc. The pins all have BAV99S and 100Ω for some ESP protection, and 33pF to help reduce noise. It is a small change, and so the existing boards are more than usable. The only snag is I mis-ordered as 1.6mm not 0.8mm boards, and I have designed cases to be as small as I can to fit in a back box. I think 1.6mm will still fit, but it is annoying.

The bigger issue is the NFC board. As I say, they work. But the tuning is perhaps not spot on. The newer design boards have a loop both sides, allowing the board to be 40mm x 40mm not 42mm x 42mm. However, the newest boards are better - the main thing is they do not get hot which is a big clue (i.e. the antenna is clearly better and easier to tune), and I have them working with more range. So I would rather use the new boards. They too are also 0.8mm which saves space.

So, all in all, I decided to order some new boards - two week lead time. However I have a few dozen of these boards. As I say, they work, and I am testing with them, and may well use some, but once I get the replacements I will end up throwing these away, I am sure, which is a shame.

So, if a hackspace, or other good cause, wants either of these bare boards, to play with. The schematics and code are all on GitHub. Note, need hot air gun at least for the PN532, and fine tipped soldering iron. Let me know. Email me at pcb1@revk.uk

Long term?

These, and some other related modules, should be able to make a WiFi mesh with (not having to be always on-line) "cloud" control and management (on or off site) to work as an alarm and access system.

Battery powered

My latest project is to make something battery powered, based on an ESP32 processor. The ESP32 data sheet claims it can go down to under 1uA in a deep sleep mode. It also has an Ultra Low Power processor that can do things in deep sleep at only a few uA. It is not very clear in the datasheet for the ESP32-WROOM-32 module how low it can go - after all that has extra bits including an external flash. So it was a bit of an unknown. However, I have made something, and it works... (on GitHub)

The first board was a cock up - wrong footprint completely on a key device - kicking myself. The second version was more what I would expect - some minor errors I could work around, allowing me to prove it all works and confirm power usage. The 3rd version was great except one of the chips again had wrong footprint - but this time close enough for the device to fit without problem. I have managed to keep the device tiny - not much bigger than the ESP32-WROOM-32 itself.

The first application is actually to work with a VL53L0X ranger in the top of an oil tank, running on battery and reporting over WiFi. The next trick may be LoRa for such things.

Battery / power supply?

The first real question was whether to try and run directly from a battery, or to use a power supply?

Directly from a battery means finding a battery that is within spec to produce 3.3V. The voltage from a battery is often slightly more (when new) than stated, and depends on the battery technology. The processor will cope with voltages a bit out of range as well (3.0V to 3.6V). So a 3V battery should work. But the voltage drops as the battery runs down, and we are starting on the edge of acceptable voltages, so this could cause problems. The advantage of running directly from a battery, apart from fewer components, is the really low power modes of the ESP32 should allow a really long battery life.

With a power supply you have the advantage of using a wide range of battery, e.g. 4.5V, 9V, 12V, etc, but the big disadvantage of wasting power on the regulator itself.

I ended up using the LMR16006 from TI which is designed for battery devices, and has an idle current of 28uA when not driving much load (e.g. an ESP32 in deep sleep). It also has a shutdown mode drawing less than 1uA (see more on that later).

However, testing showed that it draws 34uA when not even connected to a load. This pretty much is explained by the 460kΩ potential divide built in to the fixed 3.3V module to drive its feedback pin. I could go for external potential divide but 460kΩ is on the top range recommended in the data sheet.

However, even 34uA is good, and can allow a battery to last years.

USB as well?

Do I need USB as well? Well, no, not really, I could have a generic programming header, but I like the USB-C connectors. They are good as a power supply when not running off battery, and make programming and debug easy. So yes, I'd like to keep the USB.

The issue is power. The USB chip (FT231X) can be powered from USB, and even work its own 3.3V I/O from that. So it can be totally off when no USB. Good.

But it is used to control EN/GPIO0 to reset and put the ESP32 in boot mode. If USB is off, the ESP32 stays in reset. Thankfully the USB chip can be configured to invert RTS and DTR if you want, so I put them through a simple transistor inverter so that when the USB is off the ESP32 is not in reset or boot mode. The result then works as expected with the debug and flashing tools in the ESP IDF.

The Tx pin to the USB when powered down was a concern, but it seems to cause no problem, and the code can turn it off immediately on start up, and in deep sleep it is not connected.

The USB chip can also feed in some useful GPIO pins, reporting when it is on (a fixed "1" on a CBUS pin), and even if it is connected to a charger not a USB device. This means the software can tell if running from battery or not, and stay awake when being used for USB debug.

How low does the ESP32-WROOM-32 go?

Well, the good news is that the ESP32-WROOM-32 does indeed use bugger all (aka 1uA) in deep sleep. This is impressive, so we are looking at under 35uA idle current for the whole board from a 9V supply when idle.

Obviously we need to wake up occasionally, but we can wake up, boot, connect to WiFi, connect to MQTT, report status, and shut down in under a second with fixed IP. Indeed, the WiFi can be in use for under half a second, which is impressive. We need to do some long term tests to confirm battery life.

Measuring the voltage?

Of course, one thing we want to measure is the battery voltage. That allows us to see if we have a low battery. It is essential for any battery based device to tell you the battery is low. The answer is a simple potential divide feeding an ADC input to the ESP32. Except that draws current! Even 1MΩ divide is 9uA at 9V, 100% of the time.

The answer is a FET, well, two FETs. I am not an electrical engineer so this needed a bit of research. One FET or transistor would not work as it had to be at the "top" of the divider. If it was at the bottom of the divider it would mean 9V going in to the ADC pin when the FET was off. But when at the top of the divider you don't have GND as a reference to drive the FET.

The answer is an N-channel FET driving a P-channel FET, all in one package. Thanks to twitter for help on this. It works! I can turn on the divider, take a reading, and turn off again. I have some resistors to ensure than when GPIOs are isolated the FET stays off anyway. Sorted.

How low can you go?

Can I do better than 35uA? Well, yes, probably. The ESP32-WROOM-32 itself goes down to 1uA or so. The regulator in shutdown goes to 1uA but as that annoying potential divider still. If I was able to shutdown and disconnect the power from the ESP32-WROOM-32, it could run off a capacitor for many seconds at 1uA.

So basically I'd need a way for the processor to turn off its own power most of the time!

The trick is ensuring that if you sleep too long, the power will come back on anyway, and indeed when first powered up.

I think I can do this with another FET, pulling the shutdown pin to GND, driven from a GPIO pin. When no power the GPIO will go to ground, pulled by parasitic diodes if nothing else, and cause the FET to go off. Of course you still have the issue of making the shutdown pin then go high when the FET is off, with the only power being the battery, so you still need that one pull up resistor. I wonder how big we can make it? If we can make it 10MΩ we waste only 1uA on that.

The same signal driving the shutdown pin could also drive a FET switching the feedback potential divider, so we turn that off too. It may need some careful design, e.g. FET at bottom of that divide, to ensure we don't fool the regulator in to supplying too much power because its feedback is not get connected, but that should not be rocket science.

For now, I'll test using the current design, idling at 35uA, and see how it goes. But I may yet make a new version that tries to turn itself off most of the time :-)

P.S. I am such a fan of solder paste now, I can't see me ordering boards without getting a stencil as well. It is so quick and so reliable, it is quite amazing really...

NFC reader works, what next

It has been a month since I came up with this crazy idea, but the NFC reader board is working really well now. To be fair, every version I have made has worked, just some better than others. The most noticeable impact on how well it works is the inductors. Using small inductors (i.e. 0603) means it is crap - needs fob flat on then antenna to do anything. Now it works around 2cm. I have changed layout a lot, changed the antenna shape, changed component size. Lots.

I have, however, learned a lot about ESD protection, layout for RF, choosing components for RF, using KiCad, and solder paste. The solder paste has perhaps been to be the biggest change as I am no longer afraid of adding passives, which previously would have been far too annoying to hand solder and take too much space. Lots of 0603s are no issue now.

So I have a nice NFC card design, thanks a lot to John for his help. I also have a nice door control module which is tiny, and only 7mm thick. Easy to fit in a back box with other stuff.

If any hack space want to have a play with one of these NFC boards, let me know. I'd be interested in feedback. Main advantages over Elechouse are red/amber/green LEDs, tamper button, door bell input, and more ESD protection.

The boards, and 3D cases, are all on GitHub.

So what next?

Well - battery power - that's what. I have made up a new regulator for my boards rather than using the Pololu boards (they really are very good!). It has an automatic ECO mode dropping to 27uA.

Planning to work on Ultra Low Power mode on the ESP32, see how low I can get it, and run from a battery.

So now I need a board that can be low power. This means the USB chip needs to be turned off when not using USB, which is fun as it means I do not want to power its I/O pins for Tx either - and the ESP32 blurts lots of debug on Tx at start up. So a small FET is in order. Also quite fun as the FT231X USB chip works the RST and GPIO0 pins, so need them to work properly when no USB power.

P.S. Why USB?

Someone asked why do I have USB at all? I used to have boards with USB-C for power, and a header for programming, but it was actually less space and easier to just fit an FT231 to the board instead of the header, so using the USB for power and serial load/debug. The battery board is perhaps an exception as it needs a couple of extra components to let me disconnect the USB, but even so, on a board this small an extra programming header would be tricky, so I decided to stick with USB serial.

Solder paste stencil

My soldering is not bad, but there are limits, and I am reaching them with the smaller and smaller components I am trying to use. Not only are the pins small, they are under the chip. A small QFN is just about doable. So I wanted to up my skills in soldering and try solder paste. I'm impressed with the result, but it was a bit of a journey.

How to do it? Get an oven, get a proper solder stencil, and get the right solder paste. You can then wipe the paste through the stencil with a plastic card, apply components and cook. It works!

So what was so hard?

Well, it was not as simple as it sounds, so here is what happened.

Laser a stencil?

I decided to try and make a stencil myself. Basically, having a proper metal stencil made adds another £50 to the cost, and someone said they had success with a vinyl cutter. I decided to try a laser. I got a cheap one off Amazon (K4 laser generic Chinese thing). Sadly the firmware simply will not laser cut, it only raster images. It looks like I could dismantle it and re-flash with something sane, but a lot of work.

Try again

So I ordered a better laser, one that actually claims to do GRBL. Again from Amazon. The GRBL firmware loader is a windows program but works from parallels, and then it just works nicely with LaserWeb on my Mac. I'm amazed at what you can get.

So what to cut to make a stencil? Well I tried mylar and it sort of melted. I tried acetate, and it sort of burned!

So I tried some actual vinyl, and that worked surprisingly well, but is just not quite accurate enough - rough edges. It would be fine for 0603 but not QFNs. Bugger.

Oh, and all of them made some nasty smells - this is why a cheap laser is not ideal - no fans. Recommend using outside!

Cut a stencil?

Next I tried an actual vinyl cutter, as someone else had managed this. How hard could it be. I decided to try and do a bit more research, and there are some nice small cutters like Cricut and Silhouette. However I see Cricut recently stopped you cutting your own designs!!! You have to pay for designs. Wow. And I could not work out what you needed for Silhouette to work. So I went for a more generic cutter/plotter that does HPGL. Using Inkcut on my Mac worked, I can cut things...

But, not quite. For a start it took a bit to work out it uses XON/XOFF. Then I found when the serial port closes at the end of the job the printer aborts and so does not finish the job (I added a delay to fix that).

It could not cope with mylar or acetate, but did cut vinyl. However, it did not make a clean stencil! The pads were not closed and the fine pads were just a diagonal line!

The answer is that I did not quite do enough research. This is a "drag blade" cutter, so the blade point drags 0.25mm behind. This would be fine(ish) for cutting large sticky back lettering, but now when the features you are cutting are not even 0.25mm wide! There are, apparently, some s/w work arounds I could try. But for now I have given up and decided to do it properly...

Try again

Update: It looks like the Silhouette printers are going to work. Seems you have to pay £50 more for being able to load an SVG, but it will load a DXF anyway. Converting SVG to DXF is easy with inkscape and free, so why would you pay £50 more. That said, I am not sure it can cope with such detail.

Use a proper stencil?

So I ordered a proper stencil - very nice. PCB Train do a good job.

I ordered some solder paste from RS, and, well, it was a disaster. It was runny and far too much solder paste, and well, useless!

Try again

I was desparing, but encouraged by people on twitter who clearly managed to do this right, I carried on. I ordered some different solder paste, just in case.

It worked first time, clean, nice, easy to use. I am impressed.

The first board made like this actually worked - well minor issue with reset, but did then work. So now to try another.

Update:

I failed to get anything to make my own stencils, but the ones from PCB Train are impressive. One trick is they charge the same for stencils up to a certain size, so I'll be adding a number of boards that I think I have finished and ready to the artwork for next stencil order anyway. If they are the same when I order the actual boards, great,  I have a stencil already. If not, then it has not cost me to do this, but it is an incentive not to move any components if I do have further changes at all before ordering.

Almost a real RF engineer!

As you will have read, I decided to trying and tackle making an NFC reader. It is my first project in any sort of RF, so a massive learning project, but also a first in terms of trying to fit small components (e.g. QFN-40) on a PCB. The QFN-16 for the FT230X was just about doable with a soldering iron, but now I am in to solder paste and re-flow oven territory (more on a later blog).

I decided to give it a go, and made an NFC board, and to my (quite frankly) shock, it worked! It worked well, in fact - seemingly at least as well as the Elechouse board. I have made some tweaks with smaller components, and that also worked. Designing a PCB can be like a never ending piece of art - always one more small tweak or improvement. I am now working on a 3rd version, with even smaller components, but this time I am starting to do it properly from am RF point of view. Instead of just drawing an antenna track and hoping (which worked, to be fair), I now have an "network vector analyser" to tell me how the antenna and tuning circuit works.

The trick is to test the antenna and make component changes, or even adjust the antenna design. Apparently all sorts of things impact the tuning including any components near it, or just bits of copper track, and so on, even the case (even if plastic). But using one of these gadgets it is possible to work out if you have the tuning right, or close, and make adjustments. I am still learning, but getting there. In that image, you can see I changed the loop length a bit, and as expected the centre frequency moved.

My plan is to have a good quality, tuned, working, NFC reader design (open sourced), that I can sell. Something that is better than the standard Elechouse boards everyone uses. Apart from better RF (well, better than all the cheap copies of the Elechouse) it has red/amber/green LED and tamper switch. This makes it perfect for any sort of access control entry reader. I'm not really expecting to make much money, but would be nice to cover the costs of getting this far and learning this stuff.

I expect to make up a few of a final design, maybe next week, and offer some (free) to people like hackspaces to have a play and give me feedback. Obviously, if they are hit, I could have hundreds properly made and sell them. But this whole project was more aimed at a learning exercise in the first place, so covering my costs would be a huge win.

It almost makes me a proper RF engineer, LOL!

Solder paste, and reflow oven

I got a cheap reflow oven off Amazon. Seems to work, but I am no expert, and there is some advice on the internet about some tweaks and improvements to that model too. However, baby steps.

I also got some solder paste. I do not (yet) have a stencil. So advice on how one uses a solder paste stencil, and what paste you get, and so on, may be useful.

This does, however, pose a problem. Whilst it is very easy to put a spot of paste on the pads for the passives, there is no way in hell I could possibly put paste on each pad on the FT231XQ or USB-C connector. The pins are too fine.

So how to do it. Well, I did wonder if just putting paste over the whole row of pads and relying on surface tension may work. But the other snag is these short turnaround boards from PCB Train have no solder resist. Still, it is worth a try...

Well, not quite. That is the USB-C connector, and you can maybe just see that the end power pads have bridged. As it happens a touch with soldering iron sorted that and all the fine pads were OK. But it is clearly not reliable. Attempts to do this on a simple QFN-16 were less good. I suspect if I got exactly the right amount of paste it might work, but generally, no. And I doubt any chance with a QFN-40.

So what now?

Well, what I was doing with the hot air gun was tinning the pads manually (easy), and putting liquid flux on the chip, and then blasting it. It worked pretty reliably, but the heat was not very controlled and you end up charing the PCB.

So will that work in the over? Well, the short answer is yes! (well sort of)

I tin the find pads, flux the chip and place on tinned pads, solder paste the passives and put them on board, and then reflow. It seems to work most of the time, but occasionally I have to heat gun and push the chip down on to the board to ensure all pins connected.

Just as well, as I have just got the new NFC boards to play with. Fingers crossed.

Well, I made one

As per my earlier blog post, I wondered if I could make a NFC card reader... Well, I have!

Tinkering

I am in a lucky position in many ways - whilst I have a "full time job", a lot of the day to day running of A&A is handled by my management team, so I can "tinker".

This means I can try things out, do R&D pretty much as much as I like, and try and make something like this NFC reader just for the hell of it. Of course there are practical applications - I have several of the Elechouse PN532 NFC readers here because we made access control and alarm systems for the office (and even sold one) which use them. I suspect we could make, and sell, these cards. But a lot of the R&D I do is speculative (and educational) - it might sell, or might lead to something that does, maybe. Indeed, my work on NFC and DESFire cards does look like it had led to a contract that is very worthwhile, but I could not have known that at the start. The more expertise we get as a company, the more we can sell.

So, to answer the questions people have asked, mainly "why?", it is mostly because I can!

Back to the NFC reader itself

I said it may be a nice idea to try and make my own reader, much like the Elechouse reader. Well, I went ahead, a proof of concept, and it works. Yes, I am shocked too.

As a version 1 board it was not perfect. For a start, it seems the data sheet for the crystal shows the underside of the chip pin out, so if you use that as the solder pads you end up back to front. Some messy soldering and wires allowed me to work around that.

I also found soldering a QFN-20 chip hard, even with my heat gun (hence the charring), so I have ordered an oven. I'll blog on that later. I may eventually progress to solder paste masks and the like. We'll see how it goes. Even so, this is all well within the grasp of the amateur / hobbiest.

I also found the LEDs would not work - apart from ordering the wrong LEDs (diode drop was more than the supply voltage, idiot), it seems GPIO P34 does not play and I can't work out why. I have read the data sheet over and over, tried loads of config changes, and it should work, but I cannot make it work (and cannot on the Elechouse boards either), so re-done using other GPIO pins.

Version 1 board - actually works!

Version 2 board

I also decided to move to smaller 0805 components instead of 1206 - simply because of the challenge of fitting all the components on such a small board. I have made a number of value changes to more closely match the PN532 reference circuit. So that is next. I also think the Elechouse boards can overload the receiver, and it meant my Amex card would not read on my board, but a component change and it does now!

But first I need to actually test the two LEDs that should work do in fact work well enough, and test the oven when it arrives. If all goes well I'll order some version 2 boards and test.

What is wrong with other boards?

If you search for NFC readers you find two main types of things you can buy: (a) a nice plastic card reader with rubber feet to sit on your desk and connect via a USB lead to your PC, or (b) a "development board" with lots of 0.1" spaced pins to allow you to tinker, usually quite large. What you don't find is a board designed to actually be used as a component in an access control system.

To be fair, the Elechouse is pretty close - it has lots of extra pads for general tinkering but is not bad. What is lacked was LEDs for feedback and a tamper switch. That is what I have added. Just to be clear, my board is not a copy of the Elechouse, and is based on the reference circuit in the PN532 datasheet.

My board is HSU (High Speed UART) only (as that is better on a length of wire than I2C), only four wires (GND/VCC/TX/RX), and a choice of connectors on either side of the board for easy use in an access system or in a nice simple case as a device on your desk connected to a PC, if that is what you want. I'll do a 3D case design as well for both.

So I actually think my board design will be a good, usable, and even sellable board. If there is any demand I may get a few hundred properly made. But it is also nice that I am making this all open source, not just the s/w drivers, but the actual PCB layouts so you can easily order and make yourself if you want.

This is the version 2 board so far... May be real boards next week.

[P.S. I have ordered these now...]

Update: The V2 board work, and I have sent to an RF engineer to check if I need to make any tweaks before making the next version.

Tooth ache

I am sure we have all had tooth ache. I rarely have to see a dentist and rarely have tooth ache, but, well, I do now, and the delay in getting to actually get it fixed is painful.

Why my whole mouth

I have seen the dentist, and he has booked me in for a filling next week. It seems that it is just one tooth, with a broken filling, and that is it. So why does it feel like my whole jaw is trying to kill me, not just one tooth. I think "referred pain" is the answer, but it is hell. At least now I know it is one tooth I know that is the problem that needs attention.

Why some times and not others

OK I understand if I eat something and get something in the broken tooth on to the nerve, it will hurt, but it is far from that simple. Eating can make it worse, and cleaning my teeth can make it better, yes. But it seems it will be hours, maybe even all day, without a twinge - I can forget I have tooth ache. But then can be hours in agony - meaning I can't think, can't sleep, can't work. There is no clue to it at all.

Right now eating a meal is challenging though.

Temporary fillings

You can buy them (amazon!) and initially they appeared to work, but then not. They don't last long and come out easily. It is now the point where if I put in a temporary filling I will be in agony, so that is no good. Shame.

Pain killers

You would think pain killers would be the answer, so here is the list of what makes fuck all difference!

• Paracetamol
• Prescription strength co-codamol
• Ibuprofen (seems to help a bit, maybe)
• Bonjela
• Infant teething granules (aka "baby crack")
• Sensitive toothpaste

What works?

The only thing that helps, and not for very long, is literally cleaning my teeth with isopropyl alcohol. Obviously used with care although not particularly toxic.

I am, however, trying more normal ethanol ingestion as well as a method to reduce the impact of the pain.

Only a few more days...

P.S. With only 2 days to go, I think I have it - the temporary filling was a problem, but because the actual problem was not where it looked, and putting the filling in the obvious hole in my tooth just forced the broken filling in to a position which caused more pain. Now I see where the issue is, I can put a tiny bit of temporary filling around the broken filling and plug the pain mostly. The clue is that the nerve does not tell you where the pain is located, that is a serious problem!

Home automation for geeks

This is mainly about bridging some of the "trendy apply shit" and "command line forever" types of working for home automation.

Background: I have done quite a bit for home automation here at the new house. There are thousands of IoT devices (smart sockets, lights, switches, all sorts). They all come with their own app, cloud service, and feature set, but thankfully most work using ESP8266 chipset and can be "reflashed" with tasmota. Tasmota is an open source IoT application, and very flexible. It is not that tasmota is "better" than the systems that come with these devices (though it usually is), more that almost any device from almost any manufacturer can be made to work in the same way with the same config. The main one I have been using of late is the Shelly 1, which is very easy to reflash and has a relay and switch input. I do, however, have a number of my own devices, including environmental monitors. The tasmota devices can do lots of automation and send messages to each other as needed. I have, however, tried to keep it simple so a light with a Shelly 1 will have the switch connected and will work the light based on the switch even with no WiFi or Internet working!

These all work over WiFi and connect to an MQTT server. MQTT allows devices to talk to each other using a "topic" (simple text string) rather than that pesky IP addressing stuff :-) But it is very much in the school of "command line" over "GUI".

Bring on apple!

I use an iPhone, but I have not bought in to their home automation. As I say, it is more "command line" for me. That is until now. After much nagging from my son, I have managed to link my Shelly 1 and other devices, including my own environmental sensors, to my iPhone!

• I have MQTT running on a Raspberry Pi in my loft. It is just apt install mosquitto. You may want to set up some security too.
• I installed homebridge. There is a Raspberry Pi image even. I just followed the instructions and it worked. Again, set a password!
• I installed the add on homebridge-tasmota plug in (just search on the plug in tab on the web config for homebridge).
• I sent a cmnd/tasmotas/SetOption30 1 to turn on Home Assistant Discovery on all my tasmotas.
• I added the homebridge to me "home" on my iPhone. It asked what room each device was in. It warns it is not an approved bridge :-)

It is worth pointing out it is not perfect. If devices are added afterwards they appear in the "room" where the iPhone thinks the homebridge is located. You can move them to the right room, and rename them, but it is not quite as stable - resetting things can move it back very easily. So I recommend getting on homebridge first then adding the bridge. It asked where each devices it when you do that. You can reset the bridge and re-add if needed.

As for my environmental monitors, I added the necessary home assistant discovery messages, and it works. I had to do a bit of trial and error, and reading the homebridge-tasmota plugin code, but managed to make it see Temperature, Humidity and CO2 properly. Again, it seems better if these are seen by the homebridge before adding the bridge to the iPhone.

But yes, it works. I am all GUI'd up now!