MoteinoM0 R2 released

MoteinoM0 is now at revision R2. Here’s a summary of changes:

  • removed castellations for the short side header, to allow better panelization and better routed side finish on the long sides. The castellations remain on the long sides.
  • the micro USB connector is slightly recessed, the front being about flush with the board edge
  • changed top silkscreen “VUSB” header pin to “Vin”
  • “Serial” changed to “Serial0” which corresponds to the board definition Serial0. Note: the main Serial is the USB serial and SerialUSB has been deprecated.
  • added “VBat” header hole on the upper header, next to “Vin”, this was a popular demand to allow connecting a battery through a header or feed the JST connected battery to external devices. More details in this forum thread.
  • minor other layout optimizations and trace thickness adjustments

Available now in the shop. Note that MoteinoM0 along with other Moteinos and boards are now also available from Welectron Germany, check it out if you’re in the EU, it’s a good time to shop from there rather than wait for months for the crippled regular mail service.

New OTA GUI v2.0 released

If you’ve been using Wirelessly Programming, a unique feature that comes with all Moteinos, you will love this new update to the OTA GUI. The main requirement for this release was the ability to change the Programmer Moteino settings right from the GUI without reprogramming through the Arduino IDE. Here is the summary of changes:

  • A few UI changes and improvements and a new settings section:

  • support for on-the-fly change of Programmer RF settings: networkIDnodeIDfrequency (in Hz), EncryptionKey (either blank for no encryption, or 16-character key), BitRate (either default or 300KBPS). Existing RF Settings can also be read from the OTA Programmer.
    Note: for the settings feature to work, the latest OTA Programmer sketch is required
  • UI no longer locks during transfer!  The GUI window can be moved/minimized, log can be cleared at any time
  • ability to CANCEL a transfer
  • ability to refresh the COM ports dropdown
  • updated instructions
  • backward compatible with older programmer/target code
  • various bugs fixes and improvements

When you change settings on the Programmer, for the OTA transfer to work, those same settings need to match on the Target (sample starter Target code here), or the target has no way to intercept any packets from the Programmer.

If you’d like to change the RF settings on the Target, then first compile the sketch with the new settings into a HEX file, transfer it as you’d normally do, then change the settings on the Programmer via this new GUI, and you’re ready to do more OTA transfers once settings match.

The ability to change to 300KBPS instantly is very useful. That makes transfers significantly faster:

As always, if you run into any issues, have suggestions or bugs to report, please don’t hesitate reach out or start a discussion in the forum.

Happy Moteino OTA-ing!

Gateway v9.1 release

The Pi Gateway software package is continuing to be improved and the latest release is v9.1.0 (see GitHub releases). It contains some breaking changes, new features, and bug fixes. This blog entry serves as a feature review, change log and update guide.

Breaking & potentially breaking changes

  • the NGINX site configuration file is now renamed to gateway instead of default and so are the references to its log files (gateway.access.log and gateway.error.log located in /var/log/nxinx)
  • settings: there is a new interface section that contains a new responsive setting. The uiTitle setting is moved to this section. See below for responsive details.
  • metrics completely reorganized as detailed below

Metrics modules restructured

The metrics.js file is now renamed to core.js and moved into a new metrics folder. Also, all the prior default mote definitions are removed from this file and broken into individual metrics files that contain all the functionality pertaining to that particular mote. They are now called metric modules. You will see a new metrics/_LowPowerLab folder containing all these default metrics modules which used to be all bundled in the former metrics.js file. The userMetrics folder is removed and any examples or other sample metrics modules are moved under the new metrics folder.

Metrics modules loading order

In addition to the metrics reorganization into modules, the main app will load everything in the metrics folder in a specific order as follows:

  • core.js module first – required
  • any other metrics module files in the metrics folder in alphabetical order (case insensitive)
  • any metric modules in metrics/subfolders (1 level deep only) in alphabetical order (both folder and file order – case insensitive)

Globalized metric modules functions & variables

Given the powerful modularity of nodeJS, we can share functions and (string, numeric) variables between metric modules. To define a global variable or function you simply have to define it with the exports prefix, example from core.js:

exports.ONEDAY = 86400000;

exports.isNumeric =  function(n) {
  return !isNaN(parseFloat(n)) && isFinite(n); //

So now ONEDAY and isNumeric() can be called across the entire application, anywhere. If you wish to make a function local (available only to that metric module) then omit the exports prefix – examples can be seen in the RadioThermostat_CT50.js  module.

Here is a sample of how the app loading the metric modules, along with their globalized members.

The loading order affects overriding of any definitions/variables/functions defined with the same names.
[04-16-20 09:39:31.274] [INFO]   *********************************************************************
[04-16-20 09:39:31.293] [INFO]   ************************* GATEWAY APP START *************************
[04-16-20 09:39:31.296] [INFO]   *********************************************************************
[04-16-20 09:39:31.302] [INFO]   LOADING METRICS MODULE [./metrics/core.js]
[04-16-20 09:39:31.307] [LOG]    |- GLOBALIZING ONEDAY
[04-16-20 09:39:31.308] [LOG]    |- GLOBALIZING isNumeric()
[04-16-20 09:39:31.309] [LOG]    |- GLOBALIZING isValidIP()
[04-16-20 09:39:31.310] [LOG]    |- GLOBALIZING isValidNodeId()
[04-16-20 09:39:31.311] [LOG]    |- GLOBALIZING determineValue()
[04-16-20 09:39:31.312] [LOG]    |- GLOBALIZING determineGraphValue()
[04-16-20 09:39:31.313] [LOG]    |- GLOBALIZING timeoutOffset()
[04-16-20 09:39:31.313] [LOG]    |- GLOBALIZING millisToFutureDate()
[04-16-20 09:39:31.314] [LOG]    |- GLOBALIZING nextSunriseOrSunset()
[04-16-20 09:39:31.330] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/doorbellmote.js]
[04-16-20 09:39:31.340] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/garagemote.js]
[04-16-20 09:39:31.351] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/motionmote.js]
[04-16-20 09:39:31.363] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/RadioThermostat_CT50.js]
[04-16-20 09:39:31.386] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/sonarmote.js]
[04-16-20 09:39:31.396] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/sprinklers.js]
[04-16-20 09:39:31.412] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/switchmote.js]
[04-16-20 09:39:31.446] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/watermeter.js]
[04-16-20 09:39:31.455] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/weathershield.js]
[04-16-20 09:39:31.466] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/examples/_example.js]
[04-16-20 09:39:31.478] [LOG]    |- GLOBALIZING ONEDAYHOURS
[04-16-20 09:39:31.479] [LOG]    |- GLOBALIZING secondsInOneDay()
[04-16-20 09:39:31.483] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/examples/_garage-auto-close.js]
[04-16-20 09:39:31.492] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/examples/_InternetSpeedTest.js]

Given these major changes, you should rewrite/break any custom metrics in their own definition files following the patterns shown in the default LowPowerLab metrics.

UI changes

New Menu buttons & app info

You can now do a Pi reboot and shutdown straight from the app menu. There is a bunch of additional information shown – versioning, RF gateway information such as frequency and uptime (if available). The main page node list header is removed, and the Show Hidden button now shows how many nodes are hidden in that list (the button toggles their visibility as before).

Metric pinning affects order on dashboard

As requested in this forum thread, the metrics will appear in the node bubble in the order they were pinned. If you unpin+pin a metric, it will become the first in the node’s info bubble.

Responsive UI

The new interface.responsive setting (boolean) determines if the UI becomes a responsive grid when it is viewed on large screens (thresholds are 768px, 1020px).

Log/Terminal & debug messages

A few significant changes happened on the terminal page to make this UI more useful and readable:

  • there is a new “Simulation” set of fields that allows simulating a node message just as if it came from the actual node (through the RF gateway’s serial port)
  • the terminal button is removed on the terminal and settings page – the terminal input fields are now always visible
  • instead of serialized JSON, serial messages from the RF gateway are now pasted in plain text and prepended with the serial port’s name
  • simulated serial messages (such as from this UI or from non-RF nodes like the CT50-Thermostat), the logs are marked as such with (simulated)
  • pressing ENTER in these fields will trigger the Send or Simulate
  • if you want to log debug messages from your RF gateway in this UI, you can simply prefix those messages with DEBUG: and all such messages are sent to all client UI terminal logs as well as in the permanent ~/gateway/logs/gateway.sys.log file (metric matching is skipped on these special DEBUG:something to log  messages). There is also a debug:heyNodeLogThisValue metric (in core.js among other special metrics) which allows you to send a debugging value from an end node, this is treated just like any other metric and is stored along with the other node’s metrics.
  • some special gateway requests can be made to the RF gateway (if it is coded to respond to them like the new PiGateway and MightyHat examples): BEEP, UPTIME, SYSFREQ, FREERAM, ENCRYPTIONKEY

Node Requests

A new experimental feature allowing you to send pending requests to nodes is available. This is a key:value pair that can be sent to a node to ask it to do something – like change a variable like transmission period, change behavior etc. There is a new button [+REQUEST] on the node details page. You can queue requests and the gateway will send them back to nodes in ACKs as they contact the gateway. This feature will require the new PiGateway or MightyHat examples which were updated and also improved with serial buffering. Your node then needs the ability to process all such requests and ACK them back to the RF gateway which in turn will ACK them to the app itself and mark that request as complete. Node requests can also fail, expire, be edited (ie updated with some new value), and repeated.

There are some special commands that the new sketches will process WRT the new node requests feature. You can see the request queue by typing REQUESTQUEUE in the terminal, the new sketches will respond with their content (or VOID if empty). You may also do things like manually VOID a certain request to a certain node (ex. 123:VOID:REQUEST), or void all requests to that node (ex. 123:VOID).

Miscellaneous other changes

  • license is now CC-BY-NC-SA-4.0
  • latest NGINX, PHP7, nodeJS/npm packages, along with app node modules updated
  • settings page Save and Cancel buttons removed – changes are now applied upon leaving the settings page
  • graphs show 1 day of graph data (vs. 8 hours previously)
  • changing the serial port baud setting automatically switches the port to the new baud without the need of restarting the application
  • npm-request replaced with native node http module – this is to handle any http requests (like for the CT50 Thermostat)
  • Fail2ban optionally installed during setup. There is a guide page that goes into some detail about adding this post install or on prior versions.
  • various setup script fixes & updates as well as:
    • ability to install last stable version or latest unreleased code
    • added symlinks to webserver access/error logs in the ~/gateway/logs directory
  • new default icons are generated at 300px to make them look better on the larger responsive grid, the icons_template.cdr is also updated
  • dashboard MENU button hidden if there is no socket connection
  • dropped PiBakery

Updating from an older version

Before you plan to try the upgrade make sure to:

  • copy-backup existing database, settings, any uploaded images and metrics files
  • backup your entire existing SD card

While it’s possible to do an in-place update, the changes are so extensive that it will take a long time to document everything and every file/script/permission that changed, and it’s very likely I or you will miss something. I recommend doing a clean install, on a new (good time to upgrade to a newer faster) SD card, then copy your old data. To do this, follow the setup guide on this page. Once everything is running and you see the gateway app run, you will need to sudo systemctl stop gateway to stop the app from running. Then copy over all your data files, images, merge old settings into the new settings.json5 file, and add any custom metrics you may have had into the new metrics folder – ensure they are formatted after the same pattern of other default files.

Current Ranger R3mk4 – new firmware & optimizations

The CurrentRanger continues to be improved especially on the firmware side, and in some hardware aspects as well. This blog is to summarize the most important changes and bug fixes with this new release:

  • UF2 bootloader – allows easy backing up of existing firmware and swapping with new firmware via a simple drag-drop action (like copying to/from a flash drive). More details and links to new firmware are given in the guide firmware page.
  • faster boot time!
  • faster ADC sampling (for auto-ranging and for USB/serial logging)
  • more linear and improved resolution ADC readings with secondary mid-range ADC reference (when this reference is active a ½ symbol is shown in the upper left corner. This reference is automatically switched for upper-range readings or when switching ranges
  • calibration information no longer printed on the product label, instead it is briefly displayed on the OLED after power-on and also output on the USB serial port. Unfortunately the EEPROM in the SAMD21 is not persistent between firmware updates, and hence you should always save this calibration information in case you plan to update the firmware.
  • Auto-off warning is now blinked on the OLED in addition to the buzzer sound. Also, the Auto-Off function timer is reset either by manual touching any pads, or by range switched when auto-ranging is enabled (previously reset only by manual touch of any pad)
  • There is now a set of commands available through the USB serial port. This allows to easily change parameters such as the calibration values, toggle logging via USB, toggle Auto-Off function. You could basically add more commands if you customize the firmware. Here are the defaults and examples of executed commands and their output:
  • Some limited number of CR3mk4 units have shipped with firmware that will always show 4.95Vbat. Use the latest firmware to correct that.
  • Better 3D printed enclosures – thanks to a brand new Prusa MK3S printer
  • Silkscreen changes: The previous “Load-” label at the input black terminal changed to “DUT+” to make it more obvious that this is not a “negative” terminal but is the positive side of the DUT. See header photo.

There are 2 essential calibration parameters: gain and LDO voltage. The LDO voltage can always be measured on any GND and 3V exposed headers. The gain has to be adjusted either with the recommended value or during measurement of a known accurate load (ex: apply the a fixed load and increase/decrease gain until the OLED reading reflects the given load). Note that the LDO voltage can slightly change based on factors such as temperature, load (ex: with/without OLED), whether charging is taking place, battery voltage. Each LDO is unique, has its own output voltage and will respond differently. If the LDO voltage swings a lot then you might need to adjust the values before a measurement to obtain the most accurate OLED/logged ADC readings.

A few continued challenges in manufacturing…

Some components like the thumb terminal (Phoenix Contact, made in Slovakia) and banana terminals (chinese) have long lead times. Right now the thumb terminal was on backorder for a month from Mouser and they just updated the lead time to an additional month. A simple component can disrupt the supply chain,  thanks to the chinese virus putting a pause to everything.

As you might have noted, PCBs and components have been hard and slow to source due to the world apocalypse we’re living through. It takes much longer to manufacture PCBs with all the pledges from the chinese makers that everything is back to “full production”.

One of the most painfully inconsistent features of chinese PCBs is the silkscreen, like most other things chinese it sucks. Look at OSHPark silkscreen, next to a chinese made PCB, any. There is no measure of comparison (and not just silkscreen). With the large graphic features on the front side of the PCB, any silkscreen quality glitches become obvious. Thankfully functionality is not affected by silkscreen, and unfortunately the magnitudes in cost difference forces PCB manufacturing to be done mostly in china. I doubt anyone else would pay $5 extra for perfect silkscreen, I certainly would only because I am quite OCD about things I use and look at on a regular basis.

The power button is hand soldered to each unit, and liquid flux is used in the process. Flux residue is removed with flux cleaner. Sometimes traces of dissolved flux may be  absorbed inside the button. At first, while this dissolved flux is still liquid, this is not a problem and the button works fine. When the flux solidifies, it can act as a film on the button internal dome, causing intermittent contact or in rare cases an apparent complete loss of contact. The most effective fix is to add a drop of flux cleaner or IPA to the button, press the button multiple times, in an effort to dissolve and loosen up any flux traces inside the button, and also absorb this solution back with a q-tip.

That’s it for now, any other minor changes will be documented in the CR guide.

Moteino SAMD 1.5.0 release

There is a major new release for the Moteino SAMD Boards Package 1.5.0. It will popup as an update reminder the next time you restart Arduino IDE, or you can go to the Boards Manager and update from there:

Here are the most significant changes in the SAMD package:

  • All MoteinoM0 and CurrentRanger boards will start shipping with the UF2 bootloader (it’s well worth a read if you’re not familiar with it). The TLDR; is: it supports sam-ba serial protocol uploads as before (via CDC serial, from bossac or via the Arduino IDE) and it also supports drag-drop updates of the firmware as well as the bootloader itself (via a MSC flash drive that appears when the M0 is running the bootloader). Extremely useful if you want to allow an end user to update the firmware and/or bootloader with a newFirmware.uf2 file drag-drop to the “flash-drive” simulated by the bootloader, without the need for the IDE. You could enter the UF2 with a RST double-tap as before, and you’d see a new “flash-drive” on your system (the CURRENT.UF2 is the actual firmware loaded in the MCU – useful to back up before an update):
  • To top off the UF2 awesomeness, MoteinoM0’s will continue to support updates of the firmware from the external FLASH-MEM chip, after an OTA upload via RFM69. The latest RFM69 library release 1.4 has been updated to support this.
  • SerialUSB is now completely removed from the MoteinoM0 and CurrentRanger variant definitions:
    • On MoteinoM0 Serial is now the USB serial, Serial0 is the UART on pins 30/31, and Serial1 is the UART on pins 0/1.
    • On CurrentRanger Serial is now the USB serial.
    • SERIAL_PORT_USBVIRTUAL is now Serial by default
  • You might notice in the MoteinoM0/CurrentRanger boards menu, there are now some options like choosing the USB stack (Arduino, TinyUSB) and more notably the Crystal selection. You can compile for the external crystal (default for MoteinoM0 R1) and “crystal-less” ie. the internal ultra low power 32.768kHz clock). When running without the external crystal, the internal clock is tuned using the USB bus clock which is very precise.

Note that the Moteino AVR boards package is now at v1.6.1. You are encouraged to update both of these packages. Older boards running the sam-ba bootloader may be flashed with the new bootloader included in the 1.5.0 package via SWD programmer. I may even offer to do this for free if you’re willing to return the board and pay for shipping back to you. Please report any bugs or issues in the MoteinoM0 or CurrentRanger forums.

Current Ranger R3 released!

CurrentRanger is now at revision R3!

I received great feedback and several threads in the forum outlined some patterns of user behavior which led me to make some improvements and hopefully eliminate some of the issues I’ve seen people run into. Here is the change log:

Reverse polarity protection

Perhaps some folks were too excited to turn the CurrentRanger on and missed double checking their battery polarity and pufff .. the charger chip released the smoke. I offered free fix/repair to a few who’ve asked, and to put this behind – R3 now ships with reverse polarity protection. If you get it wrong, nothing happens, including the obvious – won’t turn on!

Redesigned 3D enclosure

The previous pillar style enclosure takes about 1h05m to print. And because of the way the mounting pillars are placed in R1-R2 the case called for PETG (stronger less brittle material) but often produced diagonal drag lines in the inside-bottom of the case, and PET tends to print stringy which requires additional cleanup. Mounting screws are now moved closer to corners, this yields more PCB area and allows the case to have top corner posts which are a lot more practical, free the bottom of the case for a larger battery and shave a whopping 18 minutes off the print time. This also yields more room for enclosing a bluetooth module inside the case while keeping the case low profile. And the case print just looks that much better in PLA (no posts that can easily snap either). I’m really happy about this improvement.

Gold terminals be gone!

I am done with Gold terminals, they are the fake news of banana terminals. There is nothing truly gold about them. I tried to like them but frankly, I found them to be more trouble than their gold appearance is worth. Being exposed makes them a short hazard, and twist-locking wiring actually rips the wires. Besides, I almost never use the input terminals since I added the green thumb terminal which makes it a snap to insert battery and project wires. Those gold terminals looked rich and fancy (until the “gold” wears off revealing the dull communist metal) and that’s where the “goods” stop. And yes – I did try many different vendors, I could not find a vendor with consistent quality and repeatability. They may be good for your speaker where you never touch and see them again, but I think not suitable for an electronic instrument.

You want Gold(less) terminals on your CurrentRanger? Be my guest, get them from wherever you can, but I won’t ship these anymore. I cant put fake on awesome. Instead the kit is now standard with low profile banana terminals – simple, compact, functional, consistent, just as or more conductive, that’s real “gold” in my e-tool box.

Moved components & features

A few folks in the forum reported damaging/snapping some of the capacitors near the input terminals, causing the unit to behave erratically – these are now moved away from the terminals to help reduce the chance of this happening. Just to give you an idea, here’s what that looked like, and what to avoid doing when mounting mechanicals around small SMD components on any board:

Misc other changes & additions:

  • the power button is moved slightly left to allow easier access when OLED is mounted
  • the charge LED is now moved next to the USB and is see-through just like all other board LEDs
  • the Bias LED is moved symmetrical to the LPF LED
  • a GND pin added to the SPI header next to the lower right mounting hole
  • minor layout changes & silkscreen additions

Silkscreen nightmares!

Since the top of the PCB serves as the user interface, the silkscreen needs to look fairly good and crisp. I went the extra mile to try and design some nice graphics and make a PCB with a bunch of traces look more attractive and professional.
Unfortunately since inception I’ve had numerous silkscreen issues because of these graphic elements (some my fault, some the fab’s fault, and some “in between”) causing several batches of panels to go straight into the trash. I painstakingly retraced all these graphic elements on the board in a vectorized form and these issues are now resolved (as far as silkscreen design goes). The fab can still screw up but hopefully that won’t happen again.

The official guide is updated, as always please read it carefully before using your unit. Here’s the SMD side:

CurrentRanger is made with great love and pride in Michigan USA, and I welcome feedback, suggestions and contributions.

Gateway V9 Released

The Pi Gateway software is now at v9.0.0, this release is a major new feature and bug fix release. This blog entry serves as a change log and feature review. Below are the main highlights.

New Node button & sample metric generators (ex: Internet Speed polling event)

Clicking New Node you may add a numeric ID node. This could be a future RF or LAN node, or a dummy node to hold data such as your internet speed over time (add the Internet Speed event and enable it).

For RF nodes, any node that starts sending data through the serial port attached RF gateway, will automatically generate a new node. For RF nodes, node IDs up to 1023 are now possible thanks to 10bit addressing. Below you can also see a node with ID 999 that reports temperature. 


A new Multigraph button on the node page allows generating a graph containing multiple metrics right on the node page. This enables you to easily compare the various metrics of a node chronologically. Clicking the far right remove button under the graph allows you to generate another graph with a different combination of metrics. There is a practical limit to how many metrics you can show since each metric can contain a lot of data and generates a separate vertical legend, so be reasonable and avoid pushing limits. Here’s such a graph showing the various metrics of an RF node:

Desktop graph scroll-zoom & double-click zoom

You may now scroll-zoom with your mouse wheel over a graph (works in all graphs) and it will zoom in and out. You can also double-click and it will zoom in. On mobile devices double tapping will zoom-in.

Edit and Delete metric data

Graphs now show lines between data points instead of bars by default. Still, sometimes it can be confusing looking at lines or bars, where the actual data points are. So you can now turn on data points. Additionally, you can edit and remove any single data point (click on specific data point to edit/remove) or range of data points (select range of data points to remove or change to a new value) if you wish by enabling the edit/delete mode using two buttons below the metric graph. Data points are automatically enabled when editing data.

Easy node image change

You can now change a node’s icon very easily to any existing icon (under the /www/images folder), or upload a new image of your choice (uploaded to /www/images/uploads). Icons should be 120x120px, if larger they are resized. Clicking the node icon:

This brings up the node icon change dialog (pick existing or upload new):

Other icon changes:

  • some default icons have changed (ex. CT-50 thermostat)
  • for consistency, all default icon nodes are now prefixed with icon_
  • rssi icons renamed to rssi_n with n=[1, 7]

New HTTPEndpoint for posting data from LAN

You may now submit data to the Gateway from any LAN device, thus enabling the use of WiFi (ESP anyone?) and network connected nodes, and also essentially removing the need of using only RF nodes. For instance:


will generate a new node (if non existent) with ID=1234, and generate two new metrics (MOTION, and temperature). If an ID is not provided, then the IP of that node becomes the ID. The generated node will always have a new _ip property which contains the IP of the sender. Other examples:

  • /httpendpoint/?MOTION&F=12    ->  ID=(valid IP)
  • /httpendpoint/    -> no update, just lastupdated timestamp

The response will be JSON of this form:
response: {"status":"success","message":"SUCCESS!","matchedMetrics":2}

Run in internet isolated LAN

All script files are now loaded locally and there is no longer a dependence on an internet connected RaspberryPi to fetch these scripts. So there is no concern running this completely disconnected or behind firewalls etc.

Title setting & Menu changes

You can set your own custom title from the settings page, don’t forget to click Save to apply changes. The menu now shows the Gateway app version, when the database was last compacted (done once daily automatically), and an option to compact the database on demand.

You can now quickly restart the app via Ctrl+Atl+Shift+R, or from the Menu as before.

Run it as a Mobile app

You can now run the application as a mobile app. A manifest.json definition that loads automatically with the web page allows you to create a shortcut via the Add To Home Screen option in your mobile device’s browser. Then clicking that icon on your home screen opens the web page like a mobile application without the extra browser bars.

New default metrics

  • It’s sometimes desirable to compare the RSSI of an RF node with the transmit level of an RF node. The new X:n metric with n=[0, 31] allows this to work nicely with the RFM69_ATC library extension and you can see the transmit level drop or rise based on the RSSI change.
  • A new TYPE:nodeType which matches the exports.motes definition of a mote in metrics.js allows to automatically pick that mote’s icon and other features like buttons. Example: when a SwitchMote is powered up, it can send a 1 time TYPE:SwitchMote token to indicate it’s a SwitchMote. You can always later override and pick the node type from the node type dropdown

Other misc changes

  • gateway.service is now run as pi:pi, and systemd will keep retrying to restart it if it crashes
  • fixed genNodeIfNoMatch setting
  • the /www/images/uploads directory is now chowned by www-data:pi during setup
  • node name/title added on the metric page – this helps determine which node’s temperature metric you may be looking at (vs. just “Temperature”)
  • ordered Node/Event type dropDowns (A-Z)
  • reworded and simplified licensing terms

Installation and upgrade path

This being such a major change with many new/renamed/deleted files, it’s a good idea to reinstall the application from scratch on a new raspbian image rather than try to do an in-place manual upgrade. This also ensures you will be running the latest and best raspbian, nginx, PHP7, nodeJs & packages, etc.

To transition your data to V9, backup the content of the /home/pi/gateway/data/dbfolder, then make a complete image backup of your currently functional previous version and store that until you are sure V9 runs smoothly on your Pi and all your old data is picked up.

Then follow the Gateway software setup steps in the official guide to install V9 to the latest raspbian image.

Once the V9 is running, to load your old data, you will need to sudo systemctl stop gateway, copy/overwrite the saved data into the new /home/pi/gateway/data/db folder, and then sudo systemctl restart gateway, and you should see all your old nodes and their data.

For any issues and bugs, please use this forum or you may submit a PR to the Github repository. Note that this change log may be edited as any loose ends are tied and before an official release is created.

SwitchMote available with PSU R3

The full SwitchMote kit is available again. I had to redesign the PSU cover and some 3D printed spacers which fit the new PSU R3. Everything is pretty much the same as before, except that there’s significantly less soldering to do. The PSU R3 is also available separately. All the small passives are now SMD soldered. There are now 4 screws that balance the cover a little better than before., and the FTDI programming header is offset from the edge.

You do the programming the same via an FTDI-Adapter and a double length male header which is provided in the kit.

SwitchMote PSU R3 release

The SwitchMote PSU is now at revision 3, here are the changes:

  • DC side is now SMD assembled, no more through hole components
  • 2OZ copper PCB
  • with the RECOM RAC02-05SGA there is no need for a fuse, only a MOV at 230V
  • although the DC side TVS footprint is left there, the specs of the AC-DC do not warrant a TVS on the DC side
  • same relay options as before – two 10A/250V relays or one 16A/250V relay
  • same control via AVR Moteino
  • optional footprint for ACS711 hall effect current sensor, this is experimental – it offers an analog output proportional to the AC current flowing through the SwitchMote relays. Adding this sensor requires cutting the main HOT trace where indicated and soldering solder jumpers on the bottom from the transducer’s DC side (isolated) to the Moteino side.
  • 4 symmetric mounting holes for a better enclosure – planning to make a 3D printed PETG enclosure and make the SwitchMote available with it

The kit will include the SMD assembled PCB along with the RECOM PSU, relays, MOV, screw terminal and headers. Optionally it can be ordered assembled at an additional cost.

New Moteino packages released for Arduino IDE

There is a new Moteino Arduino core package release (v1.4.0). If you’ve used the Moteino package so far with the Arduino IDE, you should get a little notice next time you start it up. By the way the link to the LowPowerLab package definition JSON is the same and should be pasted in your Preferences dialog under Boards Manager URLs:

Then you can either install or upgrade to the latest AVR package. Notice there is a brand new Moteino SAMD package with a new MoteinoM0 board as well, more on that in a separate post. Install/upgrade these in your Boards Manager:

These two packages includes a refined selection of taget boards:

  • [ Moteino / Moteino-USB ] – use this to send your sketch to a Moteino or MoteinoUSB
  • [ Moteino (8Mhz) ] – for 8Mhz Moteinos 
  • [ MightyHat ] – technically identical definition to Moteino but use this to target a MightyHat
  • [ MoteinoMEGA / MoteinoMEGA-USB ] – use this to program MoteinoMEGA or MoteinoMEGA-USB
  • [ MoteinoM0 ] – a new Moteino based on SAMD21 Cortex M0+!

Once the packages are installed or upgraded you should see these new boards in your Tools>Boards menu:

And if you’re using my custom IDE board/port shortcut bar add-on, you can quickly add and access them directly from a click of a button, no more searching in the mile long Boards submenu of doom:

Some notable changes in these new packages:

  • added standard LED_BUILTIN pin macro definitions for all boards, you can simply use this macro to address the onboard LED of any Moteino, no more need for specific checks of what board it is you’re targeting, the LED_BUILTIN will just work. This macro references D9 on 328P Moteinos and MightyHat, D15 on MoteinoMEGAs, and D13 on MoteinoM0, simply use this macro directly in your sketch:
  • added board macro definitions for all Moteino boards:
  • added SS_FLASHMEM macro pin definitions for all Moteinos, again this is to ease the use of the SPI CS/SS selection pin across all Moteino boards:

I hope you find these changes useful. There’s lot of work to be done to upgrade all the sketches in the RFM69 and SPIFlash libraries to make use of these new macros. Please report any issues and stay tuned for the coming updates on MoteinoM0!