@Eduardo_Mtz So the Edge gateway has the same default IP as my local router. Could that be an issue? Should I change the Edge IP??
Hi,
I was writing a longer message below which I’ll leave there, but yes this would likely be the issue. The Gateway is trying to send internet requests to itself. You can change the IP address of the Gateway’s internal network from Network > LAN > Edit LAN1. I attached a screenshot of an example value to change these to of 192.168.88.1, be sure to also change the IP Pool fields as well to match as in the example screencap attached.
Are you on a corporate network? They can sometimes block access to sites like Github.
Can you log into the dashboard for the network configurations of the gateway and check if it states that it has internet? You can access this dashboard by using the same url you use for node-red, just without the :1880
Can you add the attached flow and use the inject button to trigger each section after a deploy? All this flow does is reach out to google and github through DNS and IP address and see if internet and DNS is working correctly. Almost no one blocks google so we use it as a test. Let me know what the msg.statusCodes are for each request or take a screencap.
If its a DNS issue you can try to rebooting the gateway or power cycling it to see if re-registration to the network sets the DNS settings correctly.
github_internet_dns_test.json (6.8 KB)
Thanks @jacob ! That was the problem. So I was able to hit the firmware package on github and got the message that it was read correctly.
When I hit the reset button on the sensor, I did not get a ‘fly’ message, I got a ‘RUN’ mode. 15 min and I have not gotten any ‘ACK’ messages back. should I hit the reset button again?
{“mac”:“00:13:a2:00:42:37:c2:85”,“type”:53,“nodeId”:4,“mode”:“RUN”,“lastHeard”:1726859295698}
Alright, upon further investigation it looks like the type 53 supports the FLY message, but the library doesn’t have it enabled. We have an update for this and I’ll be pushing out a new live version of the library on Monday. If you want to do this today you’ll need to install the development version of the library. I’m attaching a flow in case you would prefer not to wait. Basically load the flow, deploy it, hit the inject button next to Dev branch exec node (bottom set of nodes), wait for it to complete, and then hit the inject node next to the Restart Node-Red node. This is a development version of the library, but most of the changes are for different sensor types so it should be stable for your use case. To revert just repeat the process, but start with the inject node next to the Production Branch Node. Let me know if you have any issues.
update_dev_library_restart.json (4.9 KB)
Sensors will usually send the FLY message after the RUN message on boot. The standard boot messages go like this:
RUN packet
sensor_data packet
FLY packet
@jacob, no worries, sounds good! I’ll wait till Monday.
Is there anything I need to do with the current firmware flow or sensor? Is it OK to power the sensor down?
Thanks for all your help - and @Eduardo_Mtz as well!
Hi @haljones422 Great! Okay, I think you can turn the sensor off for now. On Monday, we will be happy to follow up.
Thank you,
Eduardo M.
Had a few unexected meetings push the timeline back, but the library is updated through npm. You should see the update option now through Node-Red’s palette manager. If not sometimes it takes time to propagate the update.
Keep in mind you will need to restart node-red after the library update. The flow I sent on Friday will have a restart node-red node to make it easy or you can reboot the gateway.
After the update you’ll want to retrigger the inject nodes set up for the sensor update.
Thanks Jacob, I understand! I’m traveling the next couple days. When I get back, will let you know ASAP!
Thanks!
Hal
Hello, I have updated the NodeRed pallet manager and updated the sensor firmware.
I can now change the transmission interval to 30 seconds, but no faster - I have it set to 10 seconds, but it still transmits at 30s intervals. I’m not sure how to use the ‘Set Skip Samples’ setting so maybe that is the issue.
Can you walk me through what I need to set to get particulate readings at 10s intervals?
Thanks!!
Hi @haljones422 Sure, in this case, you could try setting the “Set Skip Samples (CO2)” and the “Set Skip Samples (Particulate)” to 1.
Thank you,
Eduardo M
Hi @Eduardo_Mtz, The current / default value seems to be set to 1. Can you explain what the setting does?
Will it enable me to override the 30s minimum?
Hi @haljones422 Could you share a screenshot of the Node-RED debug window showing the sensor data, in order to confirm if the sensor was updated to firmware version 9?
@Eduardo_Mtz When I ran the update flow, I got all the ACK messages and then the last 2 messages with all ‘true’ values. Looking back, I thought I was on version 8 - should I be on 9 or 10?
I can re-run the firmware update over the weekend and I’ll copy the debug logs this time and send them to you.
-HJ
Thank you, no, I think the sensor_data message looks good and the firmware version is correct: v9. (This means that the firmware upgrade from v8 to v9 was successful.) It is interesting.
when you set the delay, can you see in the config results 'id_and_delay: true’? something like this:
I’m going to say yes, but I will do it again to make sure and screen cap it. I’m in a client meeting the rest of the day. I will do it tomorrow and post the log and we can pick up Monday.
Have a good weekend, Thanks!
Got it. You too—have a good weekend! I’ll stay tuned.
Thank you,
Eduardo M.
Hi @Eduardo_Mtz , attached is the cap of the config response. I did it through setting manual configuration mode.
I have tried several values, but anything under 30 seconds just defaults to 30.
I’m in meetings this afternoon, so might be a bit delayed.
Hi @Eduardo_Mtz , do you have any new information on how to get the delay interval below 30 seconds? I’m still not clear on exactly what the “Set Skip Samples” setting does. I have it set to the default of 1. What does increasing the value do to my transmission or telemetry?
Thanks!
Hal
Hal,
The off the shelf sensor works like this
it will wake up, starts sampling data and discard the few samples because they could contain unstable data and once it goes passed the number of skipped samples it collects the data and sends over wireless and goes back to sleep.
The min sampling interval is hardcoded to 30sec to give the sensors enough time to samples and discard the unstable data.
If you want to get data at a faster rate then the device has the be powered on externally and we will need to keep the sensor powered on all the time and reduce the skipped samples ( this will require a firmware modification)