Anybody experimenting with node-red-mcu?

General
1

Hi folks,

So many interesting things, so less free time...

This winter I need to install a lot of sensors in my home. Currently I am using EspEasy on my ESP32 boards, and I am very pleased with it. But my ultimate dream is to have running Node-RED all over the place. Now at last there is a way to accomplish that: by using node-red-mcu from @phoddie, in combination with the node-red-mcu-plugin from @ralphwetzel.

But since this project is in early development, I found it very difficult to determine if it might be useful for me in the future. Because at the moment e.g. the list of supported sensors/boards/... is still rather limited. So I asked them some noob questions yesterday (see here), and those guys are really very helpful and open to support new features (sensors, ...).

So I would like to ask a favor from this community: are there any folks that can experiment a bit with this new technology, and share their experiences here with us. We have some very talented folks in our community, with a lot of knowledge about ESP32/ESP8266 boards. It would be really helpfull to see some tutorials arriving, to get people (like me) started quickly.

I truly believe this project has a lot of potential for us. And projects like this one can use all the help they can get...

Thanks for anybody giving it a go!!!!

Bart

2 Likes
2

I would so love to have time to play with that, but at the moment I just can't :frowning:

2 Likes
3

Sorry Bart, not going to happen here I'm afraid.

I've been rebuilding my sensors to use ESPHome which I've found very reliable and flexible but mostly uses simple configuration but allows C++ code if you need something bespoke (e.g. standardising output for ESP's with displays).

As I can run this on even the meanest of ESP8266's right through to the most powerful ES32, it is a far better option for me at the moment. Especially since you can (and I have) split the config into separate common files. Making the config for each individual device just a matter of a series of file includes and changing the name & IP.

For me, what I ask of a microprocessor IoT platform is very different to what I ask of my home automation server so Node-RED is of much less value there. Perhaps that will change in the future.

1 Like
4

Yes like the HomeAssistant community has supported EspHome, I can only pray that this community will embrace node-red-mcu...

Of course if you want to get up and running quickly, you should use an existing technology. But I will choose the hard way (again), to try to support these guys.

P.S. they also have an option to code in C.

And last but not least: they have already ordered my 2 sensors and will try to implement them :star_struck:

2 Likes
5

@TotallyInformation – thanks for sharing your thoughts. I'd like to respond to a couple of points. I may not change your mind, but at least you'll have the facts.

...but allows C++ code if you need something bespoke...

Node-RED MCU Edition is built on the XS JavaScript engine in the Moddable SDK. The native interface in XS is "XS in C" which lets you bind JavaScript to C and C to JavaScript. Most projects don't need it, but it is great to have as a fallback.

As I can run this on even the meanest of ESP8266's right through to the most powerful ES32...

As does Node-RED MCU Edition. :wink: It Edition runs on baseline ESP8266, ESP32, and Raspberry Pi Pico. In my presentation at Node-RED Con, I showed it running on an ESP8266-powered lightbulb.

Especially since you can (and I have) split the config into separate common files. Making the config for each individual device just a matter of a series of file includes and changing the name & IP.

This sounds similar to our project manifests. In the Node-RED model, I suppose that would be done with the Environment Variables feature (which is working nicely in Node-RED MCU Edition)

2 Likes
6

For people that are wondering what this is all about, please have a look at this video from Peter about node-red-mcu. Then you can see how easy you can run Node-RED on your microcontrollers, even with UI stuff :exploding_head:

Of course the amount of supported hardware (sensors, ...) is pretty limited in this early stage. But with some interest/support from our community, I am convinced they will manage to solve that...

1 Like
7

This is fantastic work! I always thought about - what if you could run "microservices" on an MCU, like a webserver - yes i know this is possible with arduino/micropython, but using node-red flows to build it is fantastic. I can imagine this is a tremendous amount of work to make flows work/compile. Best of all is that you can create things with tools I already like to work with: node-red, while it could act like esp-home/easy but with your own logic. Great stuff, thanks!

2 Likes
8

Thanks for that. I guess the question from me would be - are there modules/nodes/??? that directly support the wide range of pre-configured sensors and controls that something like ESPHome has?

For example, here is the configuration file for a BH1750 light sensor:

# BH1750 Ambient Light Sensor - https://esphome.io/components/sensor/bh1750.html
- platform: bh1750
  name: "Lux"
  address: 0x23
  measurement_duration: $light_sensitivity
  # resolution: 0.5
  update_interval: 60s
  state_topic: $mqtt_prefix/BH1750/Lux

or this for an SHT30 temperature & humidity sensor:

  - platform: sht3xd
    temperature:
      name: "Temperature"
      id: temperature
      state_topic: $mqtt_prefix/SHT30/Temperature
    humidity:
      name: "Humidity"
      id: humidity
      state_topic: $mqtt_prefix/SHT30/Humidity

That is all that is needed in order to send the sensor outputs to MQTT.

Not trying to take away from that amazing work that has been done with node-red-mcu, only saying that I'm not sure it makes sense for me. I don't want the MCU's to do lots of complex things. I want them mostly to simply & reliably send me data and occasionally respond to a button. Node-RED on my home automation server does the complex things anyway.

Of course, other people may well be wanting more complexity in the MCU and I would certainly consider this project for that purpose.

I run web servers on all of my MCU's. They show the available outputs, current config, allow changing of settings and OTA updates. Most of the firmwares have these capabilities.

9

Hi Julian,
If you prefer using yaml files instead of configuring and wiring nodes, I would advice you to have a look at HomeAssistant as well and just drop Node-RED entirely :rofl:

Anyway we are going a bit off-topic. It was not my intention to discuss here all the alternative firmwares (which we already know), but instead making Node-RED and dataflow lovers a bit warm to run flows also on their microprocessors.

And indeed the current set of sensors is rather limited - as mentioned already a couple of times above. But hopefully that will improve in the near future.

1 Like
10

Ah, no. I've already said that I use Node-RED for complex processing. I've tried using HA multiple times and find that it only gives me headaches and not any value over writing the logic myself in NR.

I look forward to seeing more - but back to my original statement, I'm afraid I won't be trying it for now.

1 Like
11

here is the configuration file for a BH1750 light sensor:

Yes and where is the logic, if else then, transform messages ?

That is the point of this project; build the complete logic flow, read/write local files, control/read GPIO, send data to databases (this is fantastic in combination with surrealdb), mqtt and whatnot, compile, flash and let it run forever. I like it a lot.

12

Sorry, I didn't include that - here are some simple examples:

binary_sensor:
  - platform: gpio # btn a
    id: M5_BtnA
    pin:
      number: 39
      inverted: true
    on_click:
      then:
        # - switch.toggle: backlight
        - light.turn_on: # Always turn on the backlight to the set level
            id: backlight
        - display.page.show: page1 # And show page 1
    # on_press:
    #   then:
    #     - output.turn_on: buzzer
    #     - output.ledc.set_frequency:
    #         id: buzzer
    #         frequency: "500Hz"
    #     - output.set_level:
    #         id: buzzer
    #         level: "1%"
    #     - delay: 15ms
    #     - output.turn_off: buzzer

  on_boot:
    priority: -10
    then:
      - wait_until:
          mqtt.connected:
      - mqtt.publish:
          topic: $mqtt_prefix/info/protocol
          payload: ESPHome
      - logger.log: Boot completed

# Wireless Signal - Quality - see https://gitlab.com/alexslx/esphome-projects/-/blob/master/templates/commons/common.yaml
- platform: template
  id: wifi_quality
  name: ${devicename} - Wifi Quality
  update_interval: ${publish_interval}
  unit_of_measurement: '%'
  accuracy_decimals: 0
  state_topic: $mqtt_prefix/status/wifi_quality
  lambda: |-
    if (id(wifi_rssi).state < -92.0)
      return 100.0;
    if (id(wifi_rssi).state > -21.0)
      return 1.0;
    else
      return round(( -0.0154 * id(wifi_rssi).state * id(wifi_rssi).state )-( 0.3794 * id(wifi_rssi).state ) + 98.182 );

I'm not denying that it will be really helpful where you need more complex logic. My point is that, for me, I rarely need much logic because the pre-configured sensors and other tooling gives me most of what I want. So the simple config is more than enough for nearly all my MCU needs. A quick dip into a lambda for some simple custom logic (as you can se in the last example) or very rarely a .h C++ include file gives me more complex logic such as what I built to have a simple "page" layout tool for the M5 Basic's built-in screen.

When there is a good range of pre-built sensors and controls, I'll be able to try it out.

13

I guess the question from me would be - are there modules/nodes/??? that directly support the wide range of pre-configured sensors

There is a large and growing suite of sensors. Just this week we added the APDS9301 ambient light sensor and the VL6180 Time-of-Flight Range Finder (which also includes an ambient light sensor).

We do something neat that makes adding new sensors to Node-RED MCU easy. There is a single MCU Sensor node that works with all the sensors. The MCU Sensor node works with Sensor classes that follow the ECMA-419 Sensor Class Pattern standard.

The MCU Sensor node has a simulation implementation that runs in full Node-RED. It generates random sample data so you can test your flows independently of an MCU. That's very useful for development.

A group of developers in Japan has been working very successfully with the MCU Sensor node. One published a great article on Qiita (even if you don't read Japanese, it is worth a look) and recently published a small book on Node-RED MCU Edition to teach others about it.

Adding support for a new sensor is generally quick and easy. That's because the sensor drivers are just JavaScript classes that follow a simple well-specified API.

That is all that is needed in order to send the sensor outputs to MQTT.

Right! That's a three node flow. I think you know how to do that already. :wink:

Not trying to take away from that amazing work that has been done with node-red-mcu, only saying that I'm not sure it makes sense for me. I don't want the MCU's to do lots of complex things. I want them mostly to simply & reliably send me data and occasionally respond to a button

Thanks for that. I get it. I think there are a some points you might consider looking ahead:

  • Node-RED Is good at doing simple things too.
  • There is a simplicity in having both the server and the sensor nodes running the same software. That lets you use the same knowledge and skills to manage both.
  • Once you have the option to put more intelligence into the sensor nodes, you might start to have ideas about all sorts of useful things you can do there too. That happened for me once I got JavaScript running in a lightbulb!
14

@phoddie,
The sensor node supports sensor classes that conform the Ecma-419. But I don't see for example anything related to power/energy/voltage in that list, even in the proposal to add new sensor types. As a result is not clear how Andy can implement the pzem-004t for me? Would be nice if you could explain that.

15

Interesting sounding stuff, will have to put FlexDash dev on pause for a while... :rofl:

Unlike Julian, I do like to run logic on my nodes. (Using micropython so far.) The primary reason is that I want stuff to work even if the wifi/network/server/Node-RED is having a bad day.
For example:

  • watering controllers: I want the watering schedule to continue regardless
  • greenhouse environmental controls: I don't want my plants to feeze/cook
  • house shutters: need to continue working else the boss comes storming in
  • weather station: continue recording and buffering data, catch up later
  • I don't have lighting controls, but again, I wouldn't want to be in the dark

The more I add to home automation the more I want "end nodes" to have some autonomy...

NB: I was running Node-RED nodes in an esp8266 back in 2016: https://groups.google.com/g/node-red/c/pJXwdl2UMQ8

4 Likes
16

I certainly recognise a possible need, just that I don't have that need myself right now since my lighting and heating controls are not ESP-based :slight_smile: For my custom sensors, I don't really care if I miss a bit of data. But that is just me. It isn't that I don't like the idea of this, merely that I don't currently have time to do anything with it.

1 Like
17

@BartButenaers, thanks for the questions about the ECMA-419 Sensor Class Pattern.

But I don't see for example anything related to power/energy/voltage in that list...

Right, it isn't there. Not yet. But that's not a problem.

As a result is not clear how Andy can implement the pzem-004t for me? Would be nice if you could explain that.

The Sensor Class Pattern is a pattern by design. Anyone can create a compatible sensor by following the pattern. To conform to the pattern, the driver must implement the four required calls - constructor, close, configure, and sample - as defined by the standard. That's pretty straightforward. For your pzem-004t, the options for configure and the output of sample will be defined based on the sensor's data sheet.

TC53 (the committee responsible for ECMA-419) accepts proposals for new sensor classes. We could roll an Energy Sensor into a future version of the standard. We want to standardize things that are broadly useful, not favoring any single manufacturer. So, when we do that, the committee looks at a variety of sensors of the same type from various manufacturers, so that the standard configure and sample options can be used by all sensors of that type. This approach has worked very nicely. For example, in projects at Moddable we've swapped in temperatures, accelerometers, and an RTC just by changing to a different ECMA-419 compatible driver -- with no code changes to the project.

I hope that makes sense. ECMA-419 is kind of a different standard in this way. Where most standards strictly limit what can be done, the use of Class Patterns in ECMA-419 provides flexibility to support new kinds of hardware in a compatible way.

2 Likes
18

Absolutely. Thanks for the introduction!!

1 Like
19

Can someone clarify how node-red-mcu and more specifically node-red-mcu-plugin works from an overall architecture perspective? I can't glean it from the docs and I have been unsuccessful getting it to run so far (open issues).

The specific question I have is how it integrates into a Node-RED environment as a whole. I understand that I create a flow, mark the flow as being an MCU flow in the plugin sidebar, and it gets compiled, yadda, yadda...

The first question I have is whether I can send messages from a regular server flow to an MCU flow and vice-versa? If so, how are they transported? If not, are the MCU flow just "aliens" in the overall Node-RED project? Or perhaps it's a "yet to come" feature?

The second question is how does "deploy" look in practice. I haven't figured out whether moddable always produces a full flash image or whether the user app (NR flows in this case) can be a thin overlay over a base system so the amount of stuff that gets flashed in an edit-experiment cycle is small.

20

If I understood correctly (see youtube link above), you use mqtt in-out nodes in your flows in both sides.