Open dachshund-digital opened 4 years ago
I have to test this scenario. Possible is due constant retries to contact with the missing sensor. At some point it should stop retrying and inactivate the node until new deployment.
Yes, I only discovered it, because I happen to be changing sensors in and out, and discovered this odd slow down side-effect. I changed my flow, adding a gate, so that the bme280 node never receives a message, unless I enable said flow. What I want to do, is somehow scan the i2c bus and only open the gate if a bmp280 or bme280 is present. Maybe your solution could be enhanced to try to initialize the sensor only if the sensor is present on the bus? Log error if sensor not found type of thing? I have 8 different sensors, across 12 devices, that report temperature, pressure, humidity, so in my python scripting I validate which sensor is present before attempt to use same. A good method for BMP/BME sensors is to query for the serial number of the sensor, if BMP do X, of BME do Y, for other sensors, search for device at the appropriate address, if MCP9808 do A, if Si702 do B, if SHT3X do C, etc., etc., if none of the above report no ambient sensor found.
Your module appears to cause the i2c scan to slow down significantly if the sensor was found, but later is not found. This should not happen, if the sensor is missing or disappears, the scan should still be quick. You can recreate this issue by adding a different sensor to the i2c bus, in place of the bme280, say a SHT3X sensor, but leave the BME280 flow in node red as is. Then run i2cdetect -y 1 and the detect scan will be horribly slow. Removing all sensors, i.e. SHT3X sensor, the scan returns to normal speed. This again can be illustrated by direct i2cdetect -y 1 from the command line. As long as your module is in an active flow, the slow down occurs, when the bme280 disappears or another sensor is on the bus other than the bme280.