TerryE

MySQL is a Node-RED node that wraps the node.js mysql2 module to provide query operations against a configured MySQL database. This enables a Node-RED flow to execute any valid MySQL queries, including SELECT, INSERT, 'UPDATEandDELETE` operations on the database.

On input uses the following msg properties to define the query:

• msg.topic holds the SQL query, and
• msg.payload optionally holds any bind values used in the query

Some query operations (e.g. SELECT) can return a result set, and this is

TerryE

/*
 * This function is more of a classical batch style "all-in" process to Query the Developer
 * REST API and load Octopus data into MySQL tables.  The mysql2 and got modules are used in
 * async mode to implement this.
*/

//------------  Functions

// Functions to convert ISOdate string 'YYYY-MM-DDTHH:mm:ss.000Z' <=>
//                               MySQL 'YYYY-MM-DD HH:mm:ss' datetime format

TerryE

// This function uses a companion HTTP Request node to load data from the OVO API
// service, with the HTTP response looped back into this node's input.
//
// -  Hence an initiating request will be cycled through this node many times
//.
// -  The state and context is maintained in msg using the msg.state object.
//
// -  msg.state.id used to sequence the cycles.
//
// -  The initiating cycle has a null state with msg.user and msg.pwd containing

TerryE

#! /usr/bin/perl
#
# Use historic readings records by my SMETS smartmeter and downloard in MySQL with Octopus
# Agile per half-hour prices to do a 2023 price comparison.
#
use strict; use warnings; use v5.10;
use DBI;
use DateTime;
use Data::Dumper qw(Dumper);

TerryE

#! /usr/bin/perl
#
# Use the Octopus rest API to download bulk price data for a given date range from the
# api.octopus.energy service and load this into a denomalised DB table, `octopus` which contains
# a dts primay key and 48  (numeric) slot fields.  Note that the JSON response can contain
# part day dats (e.g the lastest day's prices stop at midnight UTC+1), so the DB load algo uses
# an UPDATE only setting the supplied fields if there are less than 48.
#
#
use strict; use warnings; use v5.10;

TerryE

More notes on the Lua Garbage Collector in the NodeMCU implementation

Background

Lua employs automatic memory management for its objects. The Lua garbage collector (LGC) uses an incremental mark and sweep (M&S) strategy, in contrast to the reference counting strategy used by Python, etc.. The LGC is quite complex, and its detailed strategy and algorithms have been changed by the Lua development team in each of the Lua 5.x versions.

As is common practice for many other FLOSS source repositories, Lua's primary program documentation is the Lua source itself. The Lua code is largelyrr clear, readable, and broadly achieves this self-documenting goal. However in my view, the LGC is an exception here and thelgc.c could do with code cleanup to make it more transparently understandable, as many aspects of its implementation are clear as mud. There is a sparsity of other technical notes, specifications, etc. relating to the LGC and much of this information relates to old Lua versions, so other

TerryE

NodeMCU Lua Reference

Introduction

NodeMCU firmware is an IoT project ("the Project") which implements a Lua-based runtime for SoC modules based on the Espressif ESP8266 and ESP32 architectures. This reference specifically addresses how the NodeMCU Lua implementation relates to standard Lua as described in the two versions of the Lua language that we currently support:

• The Lua 5.1 Reference Manual and
• The Lua 5.3 Reference Manual (LRM)

Developers using the NodeMCU environment should familiarise themselves with the 5.3 LRM. The Project provides a wide range of standard library modules written in both C and Lua to support many ESP hardware modules and chips, and these are documented in separation sections in our online documentation.

TerryE

--[[SPLIT MODULE ftp]]

--[[ A simple ftp server

 This is my implementation of a FTP server using Github user Neronix's
 example as inspriration, but as a cleaner Lua implementation that has been
 optimised for use in LFS. The coding style adopted here is more similar to
 best practice for normal (PC) module implementations, as using LFS enables
 me to bias towards clarity of coding over brevity. It includes extra logic
 to handle some of the edge case issues more robustly. It also uses a

TerryE

#! /usr/bin/env lua
--[=[
  The purpose of this utility is to convert one or more Lua source files into an include block
  suitable for inclusion into the Nodule "fast" C module.  Files are treated in one of two
  categories: plain and chunked.  A plain file is treated as a single chunk.  A chunked file
  is identified by having a special SPLIT MODULE comment on the first line and is divided into
  separate chunks using the special SPLIT comments:

  --[[SPLIT MODULE name  Module name.  <the rest of the line is not parsed>

TerryE

// Module for interfacing with system
#include "module.h"
#include "lauxlib.h"
#include <string.h>
#include "user_interface.h"

#define LUA_USE_MODULES_FAST

static int compile (lua_State *L, int ndx) {
  size_t l;