Trying to read my first sensor (HC-SR04)

[bartbutenaers]

Hi everybody,

I have my first simple flow running on my WT32-ETH01 board: an inject node sends every 5 seconds a message via an mqtt-out node to Node-RED. That works fine, so I would now like to measure distance using an HC-SR04 ultrasonic sensor:

So I have added a Sensor node to my flow:

These are the settings of the Sensor node:

My flow doesn't do anything, i.e. no messages arrive anymore in my MQTT broker. So I must be doing something wrong. Some questions:

1. Not sure whether I understoond the pin number fields correctly. Do I need to enter (GPIO0)14 and (GPIO0)15, or perhaps 19 and 20?
2. I see in this page some explanation that we need to add some stuff manually to the project manifest file. I use Ralph's sidebar, so I assume I need to add it to this file:

   /home/pi/.node-red/node_modules/@ralphwetzel/node-red-mcu-plugin/node-red-mcu/manifest.json
   

   In that file I see following:

   {
      "include": [
    	  "./manifest_host.json"
      ],
      "modules": {
    	  "*": [
    		  "./main",
    		  {
    			  "source": "./flows",
    			  "transform": "nodered2mcu"
    		  }
    	  ]
      },
      "preload": [
    	  "flows"
      ]
   }
   

   Do I need to replace that by the following driver file, or do I need to add it somehow to the above file?

   {
      "modules": {
    	  "embedded:sensor/Proximity/HC-SR04": "$(MODDABLE)/modules/drivers/sensors/hc-sr04/hc-sr04"
      },
      "preload": [
    	  "embedded:sensor/Proximity/HC-SR04"
      ]
   }
   

3. Are there any other ways to see what is going wrong? My xsbug-log is listening but don't see anything appearing...

Thanks!!
Bart

[bartbutenaers]

or do I need to add it somehow to the above file?

I had also tried to merge both files, but after that the flow also does not send any messages:

{
	"include": [
		"./manifest_host.json"
	],
	"modules": {
		"*": [
			"./main",
			{
				"source": "./flows",
				"transform": "nodered2mcu"
			}
		],
		"embedded:sensor/Proximity/HC-SR04": "$(MODDABLE)/modules/drivers/sensors/hc-sr04/hc-sr04"
	},
	"preload": [
		"flows",
		"embedded:sensor/Proximity/HC-SR04"
	]
}

[colinl]

I have successfully used used the DS18B20 node and the Analogue input nodes from the mcu set. You should not have to do any messing with manifest files I don't think. At least I didn't. This is running on a laptop with a Wemos D1 Mini connected via USB.

Are you using the plugin direct from github? There have been some improvements recently and I don't know whether the plugin has been released to npm. I have been running from github and re-installing the node occasionally to make sure I get the latest plugin and the latest node-red-mcu.

If still no joy then it might be an idea to get it going direct using node-red-mcu initially. Then you will know whether the problem is with the plugin or with node-red-mcu or hardware etc.

[bartbutenaers]

Hi @colinl,
Thanks for joining!!!!

Yes I had installed the plugin from github (version 1.2.1-post), so node-red-mcu is installed automatically as a dependency.

I had first tried it without messing with the manifest file, but since that didn't work I tried to change it a couple of times. But I got no response at all from the board.

Had hoped to see some informational messages arriving in my xsbug-log, to tell me that I had configured it incorrectly. But nothing appears there either, so I don't have a clue what I am doing wrong...

[phoddie]

I have my first simple flow running on my WT32-ETH01 board: an inject node sends every 5 seconds a message via an mqtt-out node to Node-RED. That works fine...

Let's take a moment to celebrate that. ;)

Not sure whether I understood the pin number fields correctly

The pin numbers are GPIO values. Your use of 15 and 14 looks reasonable. (I recall that for the original Raspberry Pi, Node-RED GPIO does not use GPIO numbers, but... that doesn't scale. The pin numbers on the board are random across different vendors. GPIO numbers are stable and don't require any remapping.)

we need to add some stuff manually to the project manifest file

Your merged manifest looks reasonable. You might want to confirm that its s being used, just in case that's the wrong file to edit. Quick hacks for that are simply to use an invalid path or to make the JSON invalid, either of which will should fail to build.

I would start by making sure that the flow is running and the sensor is working. So...

1. Remove the MQTT Out
2. Connect the sensor to a Debug Node so you can monitor its output
3. Add an inject node connected to the debugger that fires immediately on launch, so you get a debug trace at start-up (to know the flow is running)
4. Have the inject node that triggers the sensor wait 10 or 15 seconds before initially triggering

FWIW – when you do get back to the MQTT Out node, the "birth message" is supported on the broker. That's a convenient way to verify that the flow is running and connects to the broker.

(I don't currently have access to my HC-SR04 sensor, so I cannot try it myself right now.)

[bartbutenaers]

Hi @phoddie,

I have modified my flow to this one:

[{"id":"45e2f062e7beecdd","type":"inject","z":"ccdecb8b3a9bc97b","name":"Every 10 seconds","props":[{"p":"payload"}],"repeat":"10","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","_mcu":{"mcu":true},"x":690,"y":100,"wires":[["816c5104e0b07c7e","c4b5be17d2e466df"]]},{"id":"816c5104e0b07c7e","type":"mqtt out","z":"ccdecb8b3a9bc97b","name":"","topic":"waterput_koer","qos":"","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"ed237c6b.40d1b","_mcu":{"mcu":true},"x":1080,"y":100,"wires":[]},{"id":"dbbd0d60d6ffce54","type":"sensor","z":"ccdecb8b3a9bc97b","name":"","platform":"","module":"embedded:sensor/Proximity/HC-SR04","options":{"sensor":{"io":"PulseWidth","pin":"15","mode":"Input"},"trigger":{"io":"Digital","pin":"14","mode":"Output"}},"configuration":"{}","_mcu":{"mcu":true},"x":890,"y":240,"wires":[["816c5104e0b07c7e","379909c25de2cb53"]]},{"id":"c4b5be17d2e466df","type":"debug","z":"ccdecb8b3a9bc97b","name":"Timestamp values","active":true,"tosidebar":true,"console":true,"tostatus":true,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","_mcu":{"mcu":true},"x":940,"y":40,"wires":[]},{"id":"1ba28b8770d25c50","type":"inject","z":"ccdecb8b3a9bc97b","name":"Every 10 seconds","props":[{"p":"payload"}],"repeat":"10","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","_mcu":{"mcu":true},"x":690,"y":240,"wires":[["dbbd0d60d6ffce54"]]},{"id":"379909c25de2cb53","type":"debug","z":"ccdecb8b3a9bc97b","name":"Sensor values","active":true,"tosidebar":true,"console":true,"tostatus":true,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","_mcu":{"mcu":true},"x":1080,"y":240,"wires":[]},{"id":"ed237c6b.40d1b","type":"mqtt-broker","name":"productie raspberry","broker":"192.168.1.162","port":"1883","tls":"ce0f0716.0b63b8","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":"","credentials":{}},{"id":"ce0f0716.0b63b8","type":"tls-config","name":"","cert":"","key":"","ca":"","certname":"","keyname":"","caname":"","servername":"","verifyservercert":true}]

On both debug nodes, I have selected all 3 output options (to get as much info as available):

This is what I see:

1. The only thing that works is that I receive every 10 seconds the timestamp value of the top inject node via MQTT in my Debug sidebar:

   

   So the MQTT stuff is working, and my flow is running.

2. But the both Debug nodes don't show any messages in my Debug sidebar. I am now a bit confused, because I "thought" that this has been working for me in the past. But don't know for sure anymore, because I have been doing quite a lot of experiments lately...

   My Debug sidebar is setup to show all messages:

   

   I also don't see the status of the Debug nodes changing in my flow editor, although I have activated the checkmark to show status updates. Not sure if that is implemented?

   Don't know it is related to this, but I also see nothing arriving in my xsbug-log via Ralph's sidebar:

   

   Note that my WT32-ETH012 is all the time connected to my Raspberry via the USB-TTL converter.

3. The sensor node also doesn't send any data via MQTT.

Again any tips are welcome!!

[ralphwetzel]

That's what I get when running your flow (on a different MCU):

#xsbug-log listening on port 5002. ^C to exit.
#xsbug-log connected to "main"
Wi-Fi connected to "[...]"
IP address [...]
# Break: importNow: module "embedded:sensor/Proximity/HC-SR04" not found!
  #0: importNow
  #1: initialize /Users/ralph/Projekte/Moddable/moddable/build/tmp/esp32/m5atom_lite/debug/mm4c7csx4o/modules/flows.js:82
  #2: call
  #3: Sensor.prototype.onStart /Users/ralph/Projekte/node-red-mcu-plugin/node-red-mcu/nodes/mcu/sensor/sensor.js:30
  #4: build /Users/ralph/Projekte/Moddable/moddable/build/tmp/esp32/m5atom_lite/debug/mm4c7csx4o/modules/flows.js:81
  #5: RED.build /Users/ralph/Projekte/node-red-mcu-plugin/node-red-mcu/nodered.js:167
  #6: (anonymous-655) /Users/ralph/.node-red/mcu-plugin-cache/mm4c7csx4o/main.js:19
  #7: (host)
mqttClient error: unknown
<warn>1679736493048
<info>{"payload":1679736493048,"_msgid":"6f7337ef0a104581","source":{"id":"c4b5be17d2e466df","type":"debug","name":"Timestamp values"}}
mqttClient error: unknown
<warn>1679736503048
<info>{"payload":1679736503048,"_msgid":"3b06db90991e2a98","source":{"id":"c4b5be17d2e466df","type":"debug","name":"Timestamp values"}}

The error message was expected. Thus I guess your flow is not running.

[bartbutenaers]

@ralphwetzel
Very kind of you to test my flow!
That is very useful info for me.

But if I keep receiving mqtt messages, then my flow is running I assume. But based on your feedback I think you must be right. Perhaps some uncleaned leftover from one of my many experiments is giving me confusing information...

• The only thing I can imagine is that for some reason my old flow is running. Will update the content of my mqtt messages tonight, to allow me to check that my last updated flow is running.

• I will also check whether the generated flow.json file contains all the new nodes I have been adding to my flow.

Are there any other things I can check? Because the flashing is succesfull

[colinl]

It might be worth using something like MQTTExplorer to montor MQTT (if you are not already) then first stop node-red to make sure that the mqtt is not originating there, then power off the mcu to make sure it then stops. Then power it on again and it should restart. Then you will at least be certain that it is something running in the mcu that is generating the MQTT. I got very confused for a while because I had a rogue flow in node red publishing to the same topic.

[bartbutenaers]

@ralphwetzel, @colinl,

I have added a function node to my flow, which simply adds the prefix "timestamp from my mcu = " to the payload of my messages:

And immediately after deploying, that change becomes visible in my MQTT Explorer:

Which means my flow is being flashed correctly, and it is running. But still no information from my Debug nodes or the Sensor node. Neither in the Debug sidebar or in the xterm terminal on Ralph's MCU sidebar.

BTW all the nodes from my flow are included in the /home/pi/.node-red/mcu-plugin-cache/t5rg16s07b/flows.json file. So my entire flow is correctly in that file.

[ralphwetzel]

And immediately after deploying ...

Immediately after what kind of "deploying"?
Pressing the Deploy button in the NR editor ... ?

[bartbutenaers]

Yes indeed my description was a bit too short for others to understand:

1. I deploy using the Build button on your sidebar, for target "deploy".
2. I wait until in the xterm window in the sidebar appears that flashing is done.
3. I deconnect the IO pin from GND to leave programming mode.
4. I power off/on the WT32-ETH01 to activate the normal mode.
5. The flow on the MCU now starts sending messages (containing the updated text) to my MQTT broker.
6. The serial wires to the USB-TTL converter remain connected all the time.

[ralphwetzel]

Hi @bartbutenaers

Looks like there's an issue in the Moddable SDK.
The version of some days ago works fine - the latest shows what you see (and what I can confirm meanwhile).

[bartbutenaers]

Hi @ralphwetzel,
Nice catch! Thought I was getting nuts, because it worked fine for you... Thanks for the analysis!!

[bartbutenaers]

@ralphwetzel,
After manually implementing the fix in my /home/pi/Projects/moddable/tools/mcmanifest.js file, I now finally see info arriving:

>> IDF_PYTHON_ENV_PATH: /home/pi/.espressif/python_env/idf4.4_py3.9_env
>> mcconfig -d -x localhost:5004 -l -m -p esp32/wt32_eth01 -t xsbug
/home/pi/esp-idf/tools/idf.py
# starting xsbug
#xsbug-log listening on port 5002. ^C to exit.
#xsbug-log connected to "main"
Skipping Ethernet setup because Wi-Fi SSID is configured.
Wi-Fi connected to "xxxxxxx"
IP address 192.168.1.31
# Break: importNow: module "embedded:sensor/Proximity/HC-SR04" not found!
  #0: importNow
  #1: initialize /home/pi/Projects/moddable/build/tmp/esp32/wt32_eth01/debug/t5rg16s07b/modules/flows.js:83
  #2: call
  #3: Sensor.prototype.onStart /home/pi/.node-red/node_modules/@ralphwetzel/node-red-mcu-plugin/node-red-mcu/nodes/mcu/sensor/sensor.js:30
  #4: build /home/pi/Projects/moddable/build/tmp/esp32/wt32_eth01/debug/t5rg16s07b/modules/flows.js:82
  #5: RED.build /home/pi/.node-red/node_modules/@ralphwetzel/node-red-mcu-plugin/node-red-mcu/nodered.js:167
  #6: (anonymous-651) /home/pi/.node-red/mcu-plugin-cache/t5rg16s07b/main.js:19
  #7: (host)
<warn>timestamp from my mcu = 1679865665054
<info>{"payload":"timestamp from my mcu = 1679865665054","_msgid":"dad67c2eb40a021e","source":{"id":"c4b5be17d2e466df","type":"debug","name":"Timestamp values"}}
<warn>timestamp from my mcu = 1679865675054
<info>{"payload":"timestamp from my mcu = 1679865675054","_msgid":"beadcb47d73ef347","source":{"id":"c4b5be17d2e466df","type":"debug","name":"Timestamp values"}}

Finally I have become aware of what is going on my MCU. That is wonderful news!!

Summarize at this stage I now have two issues left:

1. The messages that arrive now for the "Timestamp values" debug node are not being displayed in my Debug sidebar of my flow editor.

2. About the stacktrace. I had added the ""embedded:sensor/Proximity/HC-SR04": "$(MODDABLE)/modules/drivers/sensors/hc-sr04/hc-sr04"" in my manifest file (see above in this discussion), and I 'think' all the required files are there:

   

. Perhaps it is easier to start with the new mechanism for the manifest files? I have to admit that the whole manifest setup is not quite clear to me... So it is very nice to see that some progress is being made to automate this part.

[ralphwetzel]

• 

There's something very interesting in this screen shot. Well ... better: It's interesting, what's not in this picture: There seem to be no messages sent by the debug node. What you see is the status channel & the xterm messages (and some unrelated stuff). No evidence yet that the debug node(s) sends data to the browser.

So the issue is neither on the MCU nor in the client code. That's very strange...
Do you run the beta or Node-RED 3.1 ?

[bartbutenaers]

Ah ok that are your xterm messages. That makes sense.
I run Node-RED 3.0.2.
So I assume I need to look at your xterm terminal only to see the result of my Debug nodes, because the Debug sidebar interaction is not implemented yet...

[bartbutenaers]

BTW thanks @ralphwetzel for providing me insights!

[ralphwetzel]

Do you see the messages of the Debug node (running in your mcu flow) in your sidebar??

Sure.

I see now that it is only being written to the xsbug log

That's only referencing the situation for xsbug ... and has nothing to do with the feedback to the editor.

because the Debug sidebar interaction is not implemented yet...

I can't follow you. Of course it is. Do you want me to send a screencast of your flow running nicely 😉 ?

[ralphwetzel]

Good morning @bartbutenaers !

I took the night to reflect about ideas to nail this down. Shouldn't be that difficult...
Let's check where we are; I understood:

• You updated your config to the latest state, which is MCU Build system check: p1.3.0 + #942132f @ m3.7.6-58-ga06dd7f.
• You're getting status updates (below the node) for the sensor node and the mqtt node.
• There's no data shown that is expected from the debug node: Neither status, nor debug side panel, nor system console.

Please object if I got something wrong!

My proposal:
Insert here as new L38 a debug probe:

    input(id, data) {
        console.log(id, data); // <== here!
        if (id)
            this.#getNode(id)?.receive(data);
    }

Why there? Downstream it's standard Node-RED functionality, upstream it's node-red-mcu(-plugin) logic.
You need to restart NR. Do you get any log data?

[bartbutenaers]

So it seems I need to focus now on this error:

# Break: importNow: module "embedded:sensor/Proximity/HC-SR04" not found!
  #0: importNow
  #1: initialize /home/pi/Projects/moddable/build/tmp/esp32/wt32_eth01/debug/t5rg16s07b/modules/flows.js:83
  #2: call
  #3: Sensor.prototype.onStart /home/pi/.node-red/node_modules/@ralphwetzel/node-red-mcu-plugin/node-red-mcu/nodes/mcu/sensor/sensor.js:30
  #4: build /home/pi/Projects/moddable/build/tmp/esp32/wt32_eth01/debug/t5rg16s07b/modules/flows.js:82
  #5: RED.build /home/pi/.node-red/node_modules/@ralphwetzel/node-red-mcu-plugin/node-red-mcu/nodered.js:167
  #6: (anonymous-651) /home/pi/.node-red/mcu-plugin-cache/t5rg16s07b/main.js:19
  #7: (host)

@colinl : based on your experiments, do you think it is better/easier for me to continue with the new proposal for manifests? Because the manifest stuff is a bit mind-blowing for me in the evenings, after a heavy day at the daily job...

[phoddie]

@bartbutenaers – What do you mean by "continue with the new proposal for manifests"?

[bartbutenaers]

@phoddie : I read quickly through the start of that page and I saw "Currently, developers have to manually edit manifest files to add the driver", so I thought it was about a new way of working so we didn't have to manipulate manifest files anymore. Which would have been nice, because I thought my stacktrace was caused by incorrect manual editing. But I have to admit that I didn't have time yet to read about the manifest files yet. And now I am off to bed, so it won't be for today either ;-)

Please illuminate me...

[phoddie]

@bartbutenaers – I have edited the text to remove "currently." Apologies for any confusion that caused. I'm curious about where you got the word "proposal" though. That does not appear in the post. It is about an implementation, starting with "I've implemented the ability", not "Here's an idea to discuss".

In short, yes, the changes eliminate the need to manually edit a manifest when using the MCU Sensor and Clock nodes. If you have MCU Sensor or Clock nodes created BEFORE these changes, they won't include the new moddable_manifest property (obviously!). There are two solutions for that - recreate the nodes or open them in the Node-RED Editor and do something to force a re-save. You can use the Node-RED Editor Export feature to confirm that the exported JSON indeed contains the moddable_manifest property.

[colinl]

based on your experiments, do you think it is better/easier for me to continue with the new proposal for manifests? Because the manifest stuff is a bit mind-blowing for me in the evenings, after a heavy day at the daily job.

Same here, I am still trying to get to grips with what I am supposed to do.

[phoddie]

@bartbutenaers – we seem to be thrashing here, chasing symptoms rather than root problems. And I absolutely do not have a clear picture of how you are working. To help get past that, I suggest we find time to collaborate in real-time. I can make some time Tuesday or Thursday afternoon (California), which should be your evening. Just let me know a convenient time. I'll set-up a Zoom link and anyone who likes can join.

[bartbutenaers]

@phoddie,
No need for apologies. As mentioned above I have not had time to read through your article good enough. So I have interpreted it incorrectly.

Your proposal is VERY generous! But indeed it might be better to do it like that, so that we can discuss this face to face. I see that we have a time difference of 9 hour, so hopefully you can find a time interval on Thursday early afternoon that is feasable for the both of us. I will upgrade tomorrow my SDK and node-red-mcu-plugin to the latest version, and make sure my wt32-eth01 setup is next to my pc. Is there anything else I should prepare to make sure we have a smooth discussion?

I will also try to remove my Sensor node and add it again, to make sure it contains the new moddable_manifest property.

[bartbutenaers]

I will also try to remove my Sensor node and add it again, to make sure it contains the new moddable_manifest property.

I have removed the Sensor node and added a new one (without manipulating any files manually), but then I get another error (see below). Hopefully you can explain me in the Zoom session how it works and what I am doing wrong, because I assume it must be something very stupid. I will put this aside now temporarily...

/home/pi/Projects/moddable/tools/xsbug-log/node_modules/saxophone/lib/static/attrs.js:28
                throw new Error('Attribute names may not contain whitespace');
                ^

Error: Attribute names may not contain whitespace
    at Function.parseAttrs (/home/pi/Projects/moddable/tools/xsbug-log/node_modules/saxophone/lib/static/attrs.js:28:23)
    at Saxophone.<anonymous> (/home/pi/Projects/moddable/tools/xsbug-log/xsbug-machine.js:28:40)
    at Saxophone.emit (node:events:513:28)
    at Saxophone._handleTagOpening (/home/pi/Projects/moddable/tools/xsbug-log/node_modules/saxophone/lib/Saxophone.js:193:14)
    at Saxophone._parseChunk (/home/pi/Projects/moddable/tools/xsbug-log/node_modules/saxophone/lib/Saxophone.js:403:22)
    at Saxophone._write (/home/pi/Projects/moddable/tools/xsbug-log/node_modules/saxophone/lib/Saxophone.js:430:14)
    at writeOrBuffer (/home/pi/Projects/moddable/tools/xsbug-log/node_modules/readable-stream/lib/internal/streams/writable.js:334:12)
    at _write (/home/pi/Projects/moddable/tools/xsbug-log/node_modules/readable-stream/lib/internal/streams/writable.js:283:10)
    at Saxophone.Writable.write (/home/pi/Projects/moddable/tools/xsbug-log/node_modules/readable-stream/lib/internal/streams/writable.js:286:10)
    at Socket.ondata (node:internal/streams/readable:754:22)
make: *** [/home/pi/Projects/moddable/build/tmp/esp32/wt32_eth01/debug/t5rg16s07b/makefile:1054: xsbug] Error 1

[phoddie]

I've never seen that error before! That error means that the xsbug-log tool is receiving invalid communication. The xsbug protocol uses XML, and here the XML parser is reporting badly formed XML. Since you are running with the MCU plug-in, the proxy is interposed between the Node-RED MCU Runtime on your device and the xsbug-log tool. We could add some tracing to xsbug-log tool to see what's going on. @ralphwetzel, perhaps you have some idea here?

[bartbutenaers]

Might that be related perhaps by my manual changes (see above) that I made in the beginning of my experiment to the manifest.json file? Not sure if I had to remove those changes. I haven't edited any other manifest files...

[phoddie]

I don't expect it is related to those (you should be able to remove them once you are up-to-date). Manifests are used to drive the build; they should not be able to cause invalid data to appear in the debugger communication.

[ralphwetzel]

@ralphwetzel, perhaps you have some idea here?

Yes. I've seen this occasionally - when data from the MCU comes over the serial line as garbage. Happens rarely - but happens.
I'll try to catch some examples...

[phoddie]

I see that we have a time difference of 9 hour, so hopefully you can find a time interval on Thursday early afternoon that is feasible for the both of us.

I can be available between 11 AM and 3 PM Thursday, which appears to be 8 PM to midnight for you. What time works for you?

I will upgrade tomorrow my SDK and node-red-mcu-plugin to the latest version, and make sure my wt32-eth01 setup is next to my pc. Is there anything else I should prepare to make sure we have a smooth discussion?

I will also try to remove my Sensor node and add it again, to make sure it contains the new moddable_manifest property.

That all seems great. In the meantime, I'll try to run a simple test with the bizarre WT32-ETH01 and HC-SR04 to refresh my memory about all those details.

[bartbutenaers]

If we could start at 11 AM for you, that would be 8 PM for me. Which is perfect for me.
I will make sure to create a step-by-step afterwards for other mcu noobs like me, to make sure your explanation can also help others.

[phoddie]

Great. Let's plan on 11 AM Thursday (California). I'll post a Zoom link here shortly before that. Looking forward to it. (Anyone else who wants to join, please do!)

[ralphwetzel]

I'll join as well...

[phoddie]

Here's a Zoom link we can use. We'll start in half an hour.

[bartbutenaers]

Morning @ralphwetzel, @phoddie,

I had very weird sensor values after our session. So I have reviewed my wiring and there was an inconsistency in my ground between the HC-SR04 and the WT32-ETH01. After fixing that, I now see correct accurate readings:

Thanks a lot guys! You are my heroes for today ;-)

Will write a tutorial now as soon as possible, so hopefully some other users start experimenting with Moddable from Node-RED.

Have a nice sunday!!

Bart

[phoddie]

@bartbutenaers – That's great news. Looking forward to the tutorial. Will your second sensor be the PZEM-0004T? ;)