Introduction

shiv90 commented on the Roadtest call for applications that the kit might good for smartlighting applications, where it can be used as a bridge between a microcontroller and an Android or iOS app for control.

 

The PAN1780 kit didn't come with an AT commandset, but does come with a different boon: the nRF52840 module on which the kit was built around is powerful enough to not need a separate microcontroller; it can be programmed just like any other microcontroller, with the added benefit of Bluetooth Low Energy connectivity.

 

This inspired a different take on this smart lighting project: automating lights and fans with the PAN1780 as the controller.

 

This project was made to test out the PAN1780's suitability as a standalone wireless remote control device.

 

The Idea is to use advertising as the signalling mechanism, where it can be detected by a BLE to MQTT bridge. There will be an automation flow that will listen to MQTT data and transform that into MQTT instructions that will be sent to appliances being controlled by a wifi-capable microcontroller.

 

BLE advertising is used since it is connectionless and uses a lot less power than connecting to a peripheral and transmitting information that way. In some ways this is similar to how Bluetooth Mesh would work, including the need for a central "manager" to coordinate the devices. This is to simulate a possible future implementation where the product would be running off on coin cell batteries.

I do want to let you know that (in the interest of full disclosure) the PAN1780 evaluation kit was sent to me as part of Element14’s Road Test program, and I’m very grateful to them for the opportunity to road test the product.

 

The other products in this review (unless otherwise noted) were purchased by me using my own funds.

 

All the opinions you are about to read are all my own; nobody is paying for this review, nor has anyone reviewed or approved the content before it was posted.

 

I will also be approaching this road test from the point of view of a hobbyist that has had some experience with similar products, but have yet to deal with them in a professional setting.

Parts and Software

This mini-project involved a few parts and pieces aside from the PAN1780. They all then work together to make a self-contained network that is easily expandable in the future.

 

Sonoff S26 and Sonoff Basic R3 programmed with Tasmota

 

 

The Sonoff S26 and Sonoff Basic R3 from iTead are wifi-equipped relays that make it very easy to remote control them via wifi. They come with the eWeLink firmware installed by default; I didn't have the patience to reverse engineer the protocol so I instead just flashed Tasmota on them. Tasmota is an open source firmware for the esp8266 line of microcontrollers, and they have great support for the Sonoff line of relays, so it wasn't a difficult decision to choose this.

 

Raspberry Pi 4B (1GB) with an External Bluetooth Dongle

I bought the Pi 4 as soon as it was launched because I wanted to have the device that I perceived would change the single board computer landscape. It was powerful for its size, and with this project I wanted it to be the central hub where network traffic would be controlled.

 

I felt I wanted more range and power (because I wanted the Pi outside of my room) so I got myself an Feasycom external bluetooth dongle that has support for Linux. This is optional though; in my testing the built-in Bluetooth antenna of the Pi was enough to capture the BT signals I was sending from anywhere in the apartment.

 

I wanted to make sure that the Pi would always be connected to the network without interruptions, so I decided to use cabling instead of wifi. Eventually I might go for PoE so that power is supplied through the cable as well, omitting the need for a separate power line.

 

PAN1780 Evaluation Kit

Of course, we have the star of the show: the PAN1780 Evaluation Kit.

 

The eval kit by itself isn't exactly convenient as a portable remote controller because it has male pin headers sticking out the bottom, which is a possible short circuit hazard. So in this case, I soldered a pair of female pin headers onto a piece of 5cmx7cm perfboard so that the PAN1780 would fit just right in. I added another piece of 5cmx7cm perfboard underneath for additional short-circuit insulation.

The PAN1780 seems to prefer being powered via the USB port (the manuals aren't clear on the proper ways to power the board through the 3v3 or the 5v pin headers, and there isn't any LiPo charging circuit like those found on the Adafruit boards) so I jigged a small, reusable battery pack composed of a buck-boost converter (to 5v), a LiPo cell, and a male micro-usb header connected to female dupont connectors.

 

Espruino, Espruino Hub, MQTT, and Node Red

Some people swear by Arduino, others like to use MicroPython (and its derivative, CircuitPython), while others experiment with Ada, TinyGo, Rust, Lua, etc.

 

I myself prefer Espruino, which allows developers to program microcontrollers via Javascript. It has grown to be a very capable platform since its roadtest at Element14 many years ago.

 

Espruino doesn't have any official boards that support the nRF52840 (and this is possibly something that Panasonic Industry might want to consider, as having community partners is beneficial for mindshare--think of the many developers who now know of ublox because of their inclusion in the Arduino Nano33 BLE and IOT products?) but it does support the nRF52840DK. Being an open source project, it wasn't that big of a deal to write a board definition file derived from the NRF52840DK, targeting specifically the pin layout of the PAN1780. However, you would still need to compile your own hex file (which isn't exactly a walk in the park) unlike the official boards where the builds are done automatically, and there is even a DFU option for remote firmware upgrades.

 

If anyone has the PAN1780 and is following along, I've attached the hex file I compiled from sources below this article. It's just a matter of unzipping the file, running nRF Connect, then adding the hex file and writing it into the board (the PAN1780 has a Jlink OB built-in). But I would still recommend building your own firmware. I've also embedded the PAN1780.py board definition file I used as a gist.

 

 

Espruino Hub is a BLE to MQTT bridge that can "watch" Bluetooth Low Energy advertisements in the environment, and convert those into MQTT messages. Since we want to have the bridge running 24x7 I thought the best place for this to run on would be a Pi as it won't use a lot of energy. Plus, the small form factor of the Pi means I can eventually mount it up on a wall or hide it off somewhere out of sight.

 

The Pi would be connected to my home network so that means any of my Sonoff devices would also have access to it. That means I can also run the MQTT and the Node Red servers on the Pi itself for a nice, self-contained solution. Backups are easier too because I just need to backup the SD card itself and the whole thing works without a re-setup.

Build

LED Bulb

I already have my 150 watt LED light setup via an extension cable in my room, which I currently turn on and off via a switch (in Mayalsia, just like in the UK, we have power switches at the power receptacles). The LED bulb is connected to mains via a power plug to E27 socket adapter.

This was probably the easiest part of the build as all I needed was to plug the Sonoff S26 between the extension socket and the E27 adapter. However, I found that the added horizontal length is a bit too much for the friction to hold the weight of the bulb securely, so I tied it to the extension socket's hook support for additional stability.

 

Fan

I also wanted to remote control my electric fan, so I wired up the Sonoff Basic R3 inside an insulated, waterproof box.

In this case, I had to cutoff the extension wires, have live and neutral connected to the Sonoff relay, and pass ground directly (since the Sonoff doesn't have any ground connections) so that anything connected to the extension socket can be switched by the Sonoff relay.

 

Pi 4B

I mentioned that I wanted to have the network hub be on the Pi. Fortunately, the Espruino Hub setup instructions target this exact use case; all I needed was to follow the instructions in the github readme.

 

After going through the installation, visiting http://192.168.your.ip:1880/ will drop you to the Node Red UI where you can create the automation flow.

 

Tasmota

After flashing Tasmota onto the Sonoff devices, it had to be configured to connect to MQTT. In this case, the MQTT server was also running on the Pi 4B.

 

Setup this way, the Tasmota device (and therefore the appliance it's connected to) can be controlled via MQTT with the topic cmd/tasmota_xxx/POWER among other things. You can see a list of Tasmota commands here: https://tasmota.github.io/docs/Commands/#power

 

Node Red

The Espruino website has a number of sample code in their page about BLE and Node Red: https://www.espruino.com/BLE+Node-RED

 

I took the Detecting Button Presses example and modified that to suit the use case.

 

Here's a quick overview of the Node red flow:

  • Each of the buttons in the PAN1780 advertise with a different characteristic id.
  • Each of them are then routed through an RBE (report by exception) filter which only passes on the message when the value changes from its previous value.
  • The payload is then changed to the payload that Tasmota expects.
  • This payload is then routed through the devices on the right (light or fan).

Here's the setup of one of the MQTT source nodes. You can see that it's advertising using the 0xFFFF characteristic uuid, which Espruino Hub then converts to an MQTT message with this predefined topic.

 

Here's the setup of the change nodes, which will fill in the payload into Tasmota commands. In this case, it's toggle. You can also put true, or off, or many of the other commands that Tasmota understands.

 

Here's the setup of the MQTT out device (which is the Sonoff relay with the Tasmota firmware). In this case, it's the Sonoff S26. It will accept Tasmota commands and act depending on what the previous node sends it (whether it's toggle, on, or off).

 

 

All of these nodes are on the left side of the Node red UI in case anyone's following along.

 

Programming the PAN1780

Espruino makes BLE programming really easy. In this case, I was also able to add in a battery percentage advertisement together with the actual functionality for controlling the devices. This is because eventually I installed it on some cheap $5 beacons that run on coin cell batteries; I want to be able to track their battery levels and prepare fresh cells when they go below a certain amount.

 

 

The important parts of the code are in the changeAdvertising function from lines 21 to 30. This function gets called whenever a button is pressed (which is setup by the setWatch statements in lines 32 to 35).

Depending on which button is pressed, the module will start advertising that characteristic. Since the pressCount variable is incremented, the RBE filter on node red will allow the message to pass through, and trigger the device.

The Espruino IDE can be ran from https://www.espruino.com/ide and uses Web Bluetooth, so you'll need to use a browser that supports WebBT if you wish to use the bluetooth console. In this case, I used Chrome as my browser (Firefox doesn't support WebBT yet). Flashing the code is a simple as connecting the "connect to" button on the upper left, choosing the PAN1780, then pressing the upload button. The code can be optionally uploaded to flash (which I chose in my case) which would survive device power off; however for development it's easier to use upload to RAM so that when you brick the device, you can just reset it and everything is clean again.

 

Demo

 

Observations

  • The availability of four buttons make it easy to assign different functionality without having to multiplex behavior (e.g. single press, double press, long press, etc).
  • The buttons were mushy and doesn't really feel "good." They are tactile, but you don't get a firm guarantee that the button has indeed been pressed. If you'd notice in the demo video above, sometimes I would try and press a button and think that I have indeed pressed it, when it wasn't actually pressed (hence the addition of the LED pulse to visually confirm that it was indeed the button press that was the issue, and not the BLE advertising not being received by the hub).
  • The reset button is placed too close to the user buttons. Many times I pressed the reset button by mistake instead of button 3. This is especially troublesome when you're using the thumb as I was; it was very easy to fat finger the reset button.
  • The left header pins (when viewed with the buttons at the bottom, as seen in the video) are too close to the button, making it quite difficult to press buttons 2 and 4 when using the left thumb (it's somewhat easier to use with the right thumb). I had to use a fingernail to push them (this effort can also be seen in the demo video above).
  • Powering the board through USB makes the Segger Jlink OB LED go haywire. I couldn't find any indication nor mention in the manual how to disconnect or at least disempower the Jlink from the power line.
  • The small board size is great for handheld operation.
  • However, the male header pins at the bottom require the use of a bottom cover to help protect the pins from short-circuits, and avoid injury to the hand.

Conclusion

The automation worked so well I decided to get some of those cheap $5 beacons with buttons and use them as remotes for the light and the fan.

These ones run the nRF52832 (instead of the nRF540) and can also run Espruino. It was just a small matter of flashing them with a custom firmware and uploading the same javascript program above, and adding their mac address to the node red automation.

 

The PAN1780 module (without the board) is small enough to fit in one of these beacons with some space leftover for sensors like accelerometers and thermometers. Plus, since the nRF52840 has a built-in voltage regulator, a manufacturer can use a small LiPo instead of a coin cell, making the beacon rechargeable and have a longer standby time.

 

It's quite a good experiment, and the eval kit (barring some of the issues I faced above) was adequate in the development of the proof of concept.

 

Also, if anyone has any questions on the implementation, feel free to ask them in the comments. I'm sure I probably forgot to explain a step or two while doing the writeup