Search results for:

But this is JS in IoT!
Completely crazy ass thing :) no competition there.
Just:

1. make affordable pricing options for business use, costs will be passed onto the clients, so it's important that this pricing remains accessible for small businesses and startups, ensuring that the cost doesn't become a barrier to entry, there could also be an option to contact you for a custom license to negotiate for like 1000+ devices or something, and if you think $5 will not work, make it $1 and name it "support for the project" and see what happens, result may surprise you,
   
2. turn your boards to license-free by default for business use,
   
3. make statement, that any solution sold with an invoice or receipt dated before the launch of the dual licensing model is considered to have a valid license
   

Have you considered adopting a dual licensing model? You could offer a full-functionality open-source community edition that's free for everyone, alongside a commercial license for businesses. This approach has been successfully used by others, such as LightGallery: https://www.lightgalleryjs.com/license/

By doing this, you can continue supporting the open-source community while also creating a revenue stream from commercial users who need additional features or support.

One crucial recommendation is to avoid setting payment terms on a monthly or yearly basis, as this scares people away. Instead, consider offering lifetime or per-project licenses, which are generally more acceptable.

If the Espruino project evolves into a highly reliable piece of software that stands out in competition with others like MicroPython, particularly by proving to run faster or offering other significant advantages, it could certainly become worth paying for.

Feature requests (ideas) to stand in that race:

1. MP is threading capabilities with common data store (variables can be declared in a global scope and accessed across multiple threads). MP on the ESP32-S3, which is a dual-core processor, does support real threading using the _thread module. This allows you to run threads on separate cores, enabling true parallel execution of threads.
   Would it be possible to have it in Espruino?
   
2. Creating a JavaScript bytecode compiler
   MP can be compiled to bytecode:
   https://github.com/micropython/micropython/tree/master/mpy-cross
   Since '.mpy' files are precompiled, MP runtime can execute them directly without the overhead of parsing and compiling the code at runtime. Have you thought of making Espruino able to execute precompiled bytecode? I guess compiling Espruino directly to machine code involves substantial complexity due to the dynamic nature of JS, but maybe creating a JS bytecode compiler would be easier? Modifying the Espruino interpreter to execute this bytecode could offer a balance between improved execution performance and manageable complexity, making it a practical enhancement for the Espruino platform.
   

C5 is new, and I can't find any boards on Ali with it but it is the first RISC-V MCU that supports 2.4 and 5 GHz dual-band Wi-Fi 6, along with Bluetooth 5 (LE) and IEEE 802.15.4 (Zigbee 3.0, Thread 1.3) connectivity.

It is designed for applications that require high-efficiency wireless transmission.

ESP32-C5 has a 32-bit single-core processor which can clock up to 240 MHz in speed.
It has a 384 KB on-chip SRAM along with external PSRAM support, 320 KB of ROM.

So cool :)

C3 and C6 boards from Waveshare have RGB led :)

This run never ends. But that's good. We have new toys to play with from time to time :)

I found out, that it works for me only when I use WebIDE: https://www.espruino.com/ide/
When I use Chrome Extension or local IDE for some reason it does not add modules.
Maybe it is my VPN, maybe there is some other problem.
But I am glad that WebIDE works at least.

I wanted to share with you where I ended with my research how to send data securely over untrusted unsecured networks using only http and sha1 - because that is all we have on those limited in memory boards. And that is what I've got.

KEY is the same on ESP and API used only to calculate SHA1.
API calculates SHA1 from data + KEY and compares it to signature.
If it is the same - that is our board.

Also it is good to have Date.now() somewhere in data to prevent API from being hacked and receive multiple copies of the same correct request. Date will prevent adding duplicated data to DB with the same date.

CLOAK is used to have little more complex API endpoint route than some obvious one.

If this helps someone, I'd be glad that I could help :)

Big thanks goes to CanyonCasa for the idea: https://forum.espruino.com/comments/13462885/

const crypto = require('crypto');
const http = require('http');
const wifi = require('Wifi');

const KEY = 'e6a7b3d2-18f4-4c2b-9d67-4f5e1c7a8b3d';
const HOST = 'someapithing.com';
const API_VERSION = 'v2';
const CLOAK = 'f47ac10b-58cc-4372-a567-0e02b2c3d479';
const LOCATION = 'see-3';
const NAME = 'oh-7';

// Salt
const generateSalt = (minimumLength, maximumLength) => {
  if (minimumLength < 1 || maximumLength < minimumLength) {
    throw new Error('Invalid length range: minLen must be >= 1 and maxLen must be >= minLen');
  }

  const characters = '0123456789abcdef';
  const charactersLength = characters.length;
  const range = maximumLength - minimumLength + 1;
  const saltLength = minimumLength + Math.floor(Math.random() * range);
  let salt = '';

  for (let i = 0; i < saltLength; i++) {
    salt += characters.charAt(Math.floor(Math.random() * charactersLength));
  }

  return salt;
};

// Send Data Securely
const sendData = data => {
  // Prepare data
  data.salt = generateSalt(16, 16);
  data.location = LOCATION;
  data.name = NAME;

  const stringifiedData = JSON.stringify(data);
  const signature = crypto.SHA1(stringifiedData + KEY).toString('hex');
  const stringifiedDataWithSignature = JSON.stringify([
    {
      data: data,
      signature: signature,
    },
  ]);
  console.log(stringifiedDataWithSignature);

  // Send
  const options = url.parse(`http://${HOST}/${API_VERSION}/${CLOAK}/device`);
  options.method = 'POST';
  options.headers = {
    'Content-Type': 'application/json',
    'Content-Length': stringifiedDataWithSignature.length,
  };

  const req = http.request(options, res => {
    console.log(`[ STATUS ] ${res.statusCode}`);
    let data = '';
    res.on('data', chunk => (data += chunk));
    res.on('end', () => console.log('[ END ]'));
  });

  req.on('error', err => console.error('[ ERROR ]', err));
  req.on('close', () => console.log('[ CLOSE ]', data));
  req.write(stringifiedDataWithSignature);
  req.end();
};

Hi Gordon,

First, I want to clarify that my intention was never to offend or demotivate anyone. I greatly appreciate the effort you put into developing Espruino and supporting the community. My comments were solely a reflection of my personal feelings and experiences.

From reading various threads in the forum, I understood that your primary focus is on generating revenue and selling Espruino boards. This makes sense from a business perspective, but it was somewhat disheartening to read that supporting ESP chips, which you seemed to view as competition, wasn't a priority for you. It felt like you were saying you would only focus on your own boards and if others wanted ESP support, they would have to implement it themselves. This perception was demotivating for me as it felt like there was no future support for these popular chips, leading me to seek alternatives.

I want to emphasize that having support for widely-used chips like the ESP32 is crucial for attracting a large and active community to Espruino. A broad user base could potentially lead to more support and even donations from larger corporations in the future. JavaScript is very popular, and many developers, including myself, would love to use it for IoT projects on the latest hardware, not older models. People often choose the most cost-effective chips for their projects to maximize their profits, and Espruino could play a significant role by making it easier for JS developers to enter the IoT space.

Your work is incredibly valuable, and I genuinely hope that Espruino continues to grow and support more hardware in the future. I look forward to seeing Espruino evolve and hopefully include support for new ESP chips someday.

All I have for you is gratitude - thank you immensely for all your hard work and dedication. This project gave me lots of fun, and got me in iot which would never happen if it wasn't for you :) You let kids that know only JS to play with iot. I am just sad that you abandoned that part where Espruino is a cheap and affordable for everyone.

Ending this answer, I would also like to share why I would buy Espruino board, and what I think would make your business part thrive:

• reliability
  
• lots of memory
  
  

Espressif chips on boards from china are faulty. They are not perfect. They are cool to play with but lack reliability. Sometimes 3 out of 5 are ok, and the rest is connecting and disconnecting, reset itself, etc.
If I would need to create a freezer temperature monitor for pharmacy, I would like the most reliable board and if Espruino board would be one, I would pay.
ESP32 and ESP8266 have limited memory for code + memory operations. I tried to make AES work but got "out of memory" error and that was confusing. I guess that at some point I would buy Espruino board with wifi if there was enough memory to set up api with ui without using storage :) That would be a game changer in fun.

Yeah, ...so, there it is. I am still on board with all of you, just don't have skills to make Espruino work on ESP32-s3 or c6, so the easiest way for me is to find something else that works. And I just wanted to let you know about it, as a feedback. I believe that giving feedback is always in a good faith because it gives someone perspective of what people want, and why they do what they do. That's it.

But I will definitely rush back, all in, asap, when Espruino will work on those new chips :)

I understand the point, but I think it's also important for Espruino to continue supporting new Espressif chips to maintain its popularity. These chips offer remarkable power and lots of fun for people to play with. The risk of losing support for these chips will not push people to buy Espruino boards. It will just lead users to opt for alternatives like MicroPython, which already supports these new models, or just stick with old boards that Espruino support.

Keeping Espruino working on the new hardware will increase its popularity and ensure its ongoing success and engagement with the developer community.

Without it, it will start loosing all that bit by bit.

I like JS, and I like the idea of writing code for ESPs in JS. But because there is no support for the new ESPs here, I just took ChatGPT and started writing code in MicroPython. And before AI, maybe that would be a problem. And maybe I would think of buying Espruino board, but today it is just too easy to do it.

But I do look forward to Espruino supporting those chips someday :)

Either way, I understand the business need of focusing on the get money part. And hope you will find a way to get what you want :)

Did it myself, just my mistake :) Doing in in a hurry.
...fixed it ;) Thx for the review :)

ESP32 Series Comparison (As of 2024)

Feature	ESP32	ESP32-C3	ESP32-C5	ESP32-S3	ESP32-P4	ESP32-H2
Processor	Dual-core Tensilica LX6	Single-core RISC-V	Dual-core RISC-V	Dual-core Xtensa LX7	Dual-core Xtensa LX7	Single-core RISC-V
Frequency	Up to 240 MHz	Up to 160 MHz	Up to 240 MHz	Up to 240 MHz	Up to 240 MHz	Up to 96 MHz
Wi-Fi	802.11 b/g/n	802.11 b/g/n	802.11 b/g/n/ac	802.11 b/g/n	802.11 b/g/n/ac	No
Bluetooth	BT 4.2 (Classic + LE)	BT 5.0 (LE)	BT 5.0 (LE), BLE Mesh	BT 5.0 (LE)	BT 5.0 (LE), BLE Mesh	BT 5.0 (LE), Thread, Zigbee
Internal Memory	520 KB SRAM	400 KB SRAM	520 KB SRAM	512 KB SRAM	520 KB SRAM	Similar to ESP32-C3
External Memory	Up to 16 MB Flash & 8 MB SRAM	Flash & External RAM Supported	Up to 16 MB Flash & 8 MB SRAM	Up to 16 MB Flash & 8 MB SRAM	Up to 16 MB Flash & 8 MB SRAM	Flash & External RAM Supported
USB	No	Yes (USB OTG)	Yes (USB OTG)	Yes (USB OTG)	Yes (USB OTG)	No
Primary Use Case	General IoT applications	Cost-sensitive IoT devices	High-performance IoT applications	Advanced applications with AI	High-performance IoT applications with AI	Smart home networks

Key Takeaways

• ESP32: Continues as a versatile choice for a wide range of applications, offering robust memory and processing capabilities.
  
• ESP32-C3: Provides an efficient, cost-effective solution for simple IoT devices that require Wi-Fi, Bluetooth, and USB OTG capabilities.
  
• ESP32-C5: Steps up as a dual-core RISC-V processor with improved Wi-Fi and Bluetooth, ideal for high-performance IoT applications that also require USB OTG support.
  
• ESP32-S3: Offers advanced AI capabilities and rich I/O options, suitable for applications requiring machine learning and USB OTG support.
  
• ESP32-P4: Newer model with enhanced AI capabilities and superior connectivity options, including USB OTG support, designed for demanding IoT applications.
  
• ESP32-H2: Focuses on connectivity for smart home applications using Bluetooth 5, Thread, and Zigbee, perfect for non-Wi-Fi dependent setups.
  

Has anyone successfully flashed Espruino on this chip?

Have you seen ESP32 S2 Mini V1.0.0 Development Board with ESP32-S2FN4R2 4MB FLASH 2MB PSRAM?

There is hope :)

I have read both Encryption threads:

https://forum.espruino.com/conversations/267841/
https://forum.espruino.com/conversations/273427/

So after 7 years we just have SHA256 in crypto for ESP build in?
I was hoping to find some AES-like included solution.

I went through git repo and read readme for building, but for windows there was only information: basically do it in Linux. Unfortunately not a solution I can use. I was hoping it can be done in Windows with Python :)

Could you add additional builds for ESP chips with AES, so there is one with and one without for each?

Hi guys :)
I found old NodeMCU Lolin v3 board and I am playing with it :)
I am wondering how to encrypt securely message on espruino and decrypt it on api.
I am looking for a way to ensure that only my device can add records to database.
I want to send only temperature and humidity so there is not much data.
I was thinking about RSA or AES or whatever can fit into this little thing.
AES would be super cool to use but require('crypto').AES doesn't seem to work after flashing with ESP8266 4MB.
Key to encrypt and decrypt message can be safely stored on the api and espruino - so that would work over unsecured networks.
I want to use HTTPS or TLS if possible, but I am just starting to look around after couple of years break from espruino project what has changed and from what I can choose from :)

I have read about XXTEA and other libraries but unfortunately failed to upload it to ESP board. Too large or too resource hungry... but still fighting :)

Or this:
https://github.com/suculent/thinx-aes-lib

This is interesting:
https://bitwiseshiftleft.github.io/sjcl/

For a 4MB ESP8266 NodeMCU board running Espruino, your choices for secure encryption libraries are somewhat limited due to the constraints of the device, including its memory and processing power.

One of the smallest and most secure encryption libraries that could fit this criterion is TweetNaCl. TweetNaCl is a cryptography library that offers a compact implementation of the NaCl library (Networking and Cryptography library), which is well-regarded for its simplicity and high security. The TweetNaCl library has been ported to various languages and platforms, and there is a JavaScript version that could potentially be used with Espruino.

Anyone, any ideas?

XOR Cipher: For very lightweight applications, a simple XOR cipher with a pseudo-random sequence generator (like a linear feedback shift register for the sequence) could be implemented. However, this method is not recommended for securing sensitive data, as it can be relatively easily broken without proper precautions.

RC4: Another small and simple option could be RC4 (although it's now considered insecure for many applications, it might suffice for scenarios with low security requirements). You would need to be careful with its initialization and usage to avoid common pitfalls that make it vulnerable.

Simplified AES (SAES): This is a reduced, more straightforward version of AES designed for educational purposes and might serve as a basis for a custom implementation. It can demonstrate how to perform secure encryption with less complexity, though adapting it for production use requires caution to maintain security.

Found those on the net, but I am open to discussion and knowledge exchange before attempt to embed any of them.

1. TweetNaCl / TweetNaCl.js - A compact, tweet-sized NaCl cryptography library, with a JavaScript version suitable for adaptation.
   
2. micro-ecc - A small Elliptic Curve Cryptography (ECC) library for microcontrollers.
   
3. uCryptoLib - A micro cryptographic library designed for embedded devices.
   
4. LibHydrogen - A lightweight, secure, easy-to-use crypto library for constrained environments.
   
5. Tiny-AES-c - A small and portable implementation of the AES algorithm, potentially adaptable for JavaScript.
   
6. BearSSL - A secure and relatively small SSL/TLS library, with potential for lightweight implementations.
   
7. mbedTLS (minimal configuration) - A library that can be configured to be minimalistic for embedded devices.
   
8. wolfSSL (with --enable-smallstack or --enable-minimal options) - A small, portable, and embeddable SSL/TLS library.
   
9. sodium-native - A low-level Node.js binding to libsodium, which might be adapted or inspire a minimal implementation.
   
10. TinyCrypt - A small, portable, and easy-to-use library of cryptographic algorithms.
    
11. speck.js - A JavaScript implementation of the SPECK block cipher, known for its simplicity and small size.
    
12. microjs/crypto - A collection of micro libraries in JavaScript, including some for cryptography, which are very small.
    
13. SJCL (Stanford JavaScript Crypto Library) - While not the smallest, it can be customized to include only necessary features.
    
14. asmCrypto - A JavaScript cryptographic library with AssemblyScript optimization, potentially adaptable for size.
    
15. js-nacl - A high-level cryptographic library that can be adapted or stripped down for essential functionality.
    
16. noble - A family of compact, secure, and easy-to-use cryptographic primitives for JavaScript.
    
17. Heatshrink - A data compression library suitable for small microcontrollers, useful for reducing data size before encryption.
    
18. PicoCrypt - A hypothetical minimal cryptographic library designed with the smallest footprint in mind.
    
19. CryptoJS (minimal build) - While generally larger, it can be customized to only include necessary components.
    
20. Salty - A minimal secure encryption library for JavaScript, focusing on ease of use and small size.
    
21. Elliptic (minimal configuration) - A lightweight implementation of elliptic curve cryptography in JavaScript.
    
22. SOSEMANUK - A fast, software-oriented stream cipher that can potentially be adapted for JavaScript environments.
    
23. Rabbit - A fast stream cipher that can be implemented in a compact form for JavaScript.
    
24. Simon and Speck - Lightweight block ciphers designed for simplicity and efficiency, potentially adaptable to JavaScript.
    
25. ChaCha - A stream cipher that offers good performance and security, with potential for a minimal JavaScript implementation.
    

You can embed the module in your code like this (and there is no need for require anymore):

function DHT22(pin) {
  this.pin = pin;
}

DHT22.prototype.read = function (cb, n) {
  if (!n) n = 10;
  var d = '';
  var ht = this;
  digitalWrite(ht.pin, 0);
  pinMode(ht.pin, 'output');
  this.watch = setWatch(
    function (t) {
      d += 0 | (t.time - t.lastTime > 0.00005);
    },
    ht.pin,
    { edge: 'falling', repeat: true }
  );
  setTimeout(function () {
    pinMode(ht.pin, 'input_pullup');
    pinMode(ht.pin);
  }, 1);
  setTimeout(function () {
    if (ht.watch) {
      ht.watch = clearWatch(ht.watch);
    }
    var cks =
      parseInt(d.substr(2, 8), 2) +
      parseInt(d.substr(10, 8), 2) +
      parseInt(d.substr(18, 8), 2) +
      parseInt(d.substr(26, 8), 2);
    if (cks && (cks & 0xff) == parseInt(d.substr(34, 8), 2)) {
      cb({
        raw: d,
        rh: parseInt(d.substr(2, 16), 2) * 0.1,
        temp: parseInt(d.substr(19, 15), 2) * 0.2 * (0.5 - d[18]),
      });
    } else {
      if (n > 1)
        setTimeout(function () {
          ht.read(cb, --n);
        }, 500);
      else cb({ err: true, checksumError: cks > 0, raw: d, temp: -1, rh: -1 });
    }
  }, 50);
};

const dht22 = new DHT22(NodeMCU.D5);

const readDHT22Sensor = () => {
  digitalWrite(D2, false);
  dht22.read(e => {
    console.log(
      '[DHT22 sensor]  ' +
        new Date().toString() +
        ' temperature: ' +
        e.temp.toString() +
        '°C, humidity: ' +
        e.rh.toString() +
        '%'
    );
    digitalWrite(D2, true);
  });
};

readDHT22Sensor();
setInterval(() => readDHT22Sensor(), 1000);

I had similar problem:

Execution Interrupted during event processing.
New interpreter error: MEMORY
ERROR: Ctrl-C while processing interval - removing it.
Execution Interrupted during event processing.
New interpreter error: CALLBACK

I send DHT22 sensor data to backend endpoint every second using http post requests.
I think I needed 7+-20 of them to show up to cause it this to happen.

Extending setInterval() from 1000 to 5000 did work.

I think the memory stores the http request until it receives callback or expires at some point, and sending too many in the same time causes CALLBACK MEMORY to run out of storage space :)

You need to find the right interval time so that the "callback memory" stack had data flow instead eventually run out of space.

http request connects to server, closes connection, waits for the response, and when it receives one, the whole thing ends and memory stack is being free from this http request, so in the meantime memory stores the request.

If you sent 50 requests and none gets response, you have 50 requests waiting for responses which causes memory run out of space to store more.

If you need the data immediately, please consider web sockets instead of http requests.

web socket opens connection and never closes it, in the meantime data flows non stop. it is used for chats but any other use when data flow is needed and considerably web socket would use less data transfer than http request is a good choice.

Has anyone successfully flashed NodeMCU with ESP8266 and CP2102 USB to UART bridge, with Espruino v1.99 and connected to using Espruino IDE?

I have Amica NodeMCU board.
I use esptool.py.
I installed UART driver (https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers#windows).
Chrome and native Espruino IDE sees USB to UART bridge on COM5.
I can successfully flash the board, but after flashing IDE returns:
"Unable to retrieve board information. Connection Error?"

I used DIO, QIO, DOUT, QOUT, 80m, 40m, 115200, 9600, espruino 8266 v1.99 and espruino 8266 4MB v1.99 (both stable and cutting edge) in all combinations I could think of, and nothing works.

However board with CH340 on the same cable flashes and works.

This is my first board with CP2102 USB to UART bridge. Any board with CH340 chip i have work with eventually flashed and connected to Espruino IDE, whether it was DIO , QIO, DOUT...

If anyone has successfully flashed CP2102 with any previous version of Espruino, I would really appreciate the info what version of Espruino and what options, whether it was some flash loader or esptool so I could repeat steps and see if this is Espruino software, driver or the board itself.

If anyone wants, I can upload your code (just paste it here), run it, and paste back the results.

The thing is...it looks like there is a build-in antena.

Board has successfully flashed with espruino v1.99.
Ddht22 sensor works ok and returns data to console
Simple wifi.connect returns no_ap_found
Surprisingly the AP is being set, but my phone does not see it.

Exactly the same code put on board with external esp8266 works.
My phone sees AP.
Dht22 sensor works.

I have different boards with esp8266 (nodemcu d1, v3, v1...) this version is the only one that does not work. My friend says that he has the same problem, however we bought it on Amazon from the same seller so I cannot exclude the factory damage. I would need to buy one from some other producer.