Terry Ellison 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.

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

	#!/usr/bin/env python
	# Minimal file downloader

	import os
	import serial
	import sys
	import argparse
	import time
	import logging
	import re

	// 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;

	#! /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>

	--[[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

	#! /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;

	#! /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);

	// 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

	/*
	* 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