Yes, udev is likely the way to do it. Fortunately, I have experience with udev. Part of the path is consistent, gvien the i2c addresses are effectively static between reboots, that much of the path is known, so really it is just why iio:device0 vs iio:device1 results that is at issue. I could just do a test loop 0<X<128, as deviceX, would be a brute force solution. Of course, if i2C bus expansion is in play there might be more than 128 devices? Moreover, not every i2c sensor is presented as an iio:device... why that is the case, not sure as yet. This is getting more interesting as I dig into it. This maybe as nasty as walking the USB bus... if you have ever done that, what a PITA. I posting to the kernel team for Pi, there has to be some logic as to why they let the paths for dtoverlay do some weird stuff.
I think you need to find an identifying attribute. I expect you know that for usb if a device mounts as /dev/sdb for example you would use
udevadm info -a -p $(udevadm info -q path -n /dev/sdb)
to find a unique set of attributes. What the equivalent would be for i2c I don't know.
True, I often use UUID or sometimes even the static serial number for USB devices with udev. For i2c, I know only two things... which bus I am on, and the device address. You can't have the same address twice on the same bus.
So for a bme280 sensor, it is going to be 0x77 on bus 1, for example. This also happens to be the one unique element in the /sys device path using dtoverlay method of device access, /1-0077/, for example. The issue is the leaf below, can be 'iio:device0' or 'iio:device1', and I don't as yet see a way with udev to handle this... except with two different rules that result in a unified 'alias' path.
I hope my query in the Pi forums, asking the Pi kernel/dtoverlay gurus for details, might illuminate the issue(s).
With usb devices you can select on manufacturer id and device serial number, for example. There must be a way of getting it to use just the bus and device address, but I haven't used i2c at all so I don't know how to do it. What does the above udevadm command show if you put the full path in where it has /dev/sdb?
Oh, there all kinds of 'attributes' you can query for on USB devices. Next day or so, I will see what I can find on the device tree for the sensors. Scanning the dmesg output should give me a clue on how and what is seen by the kernel during boot or early load sequence.
LOL... looks like my bme280 sensor goes offline at times. Once in a while the test flow I have running every 15 minutes to query the bme280, returns a remote I/O error, i.e. the kernel driver fails send commands to the sensor.
[14537.332194] bmp280 1-0077: failed to write ctrl_meas register
[14537.333223] bmp280 1-0077: failed to read temperature
Worse... the driver does not qualify bmp280 vs. bme280? Not good. If you query a bme280 as a bmp280, that is a dirty short-cut. But I digress.
Any address listed as UU means the kernel level driver owns the device. If the actual device addres is shown, that means device is on the i2c bus, and userland applications can access the device, i.e. you can do direct read/write commands on the bus, to specific device.
$ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: UU -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- UU
So, for 0x40, 0x48, and 0x77, the dtoverlay method is engaged. But not for 0x60 device. This matches the device paths:
If you have a unique identifier for udev then you can tell it to create a symlink to it from a defined mount point can't you? Then you can always access it via that.
That is my thinking, or something similar.
Just for reference, the raw device paths, for the bme280 sensor:
pi@pi4modelb0:~/max7219-dachshund-digital/examples $ sudo find / | grep bus | grep 1-0077
/sys/bus/i2c/devices/1-0077
/sys/bus/i2c/drivers/bmp280/1-0077
pi@pi4modelb0:~/max7219-dachshund-digital/examples $ sudo find / | grep device | grep 1-0077
/sys/devices/platform/reg-dummy/regulator/regulator.0/1-0077-vdda
/sys/devices/platform/reg-dummy/regulator/regulator.0/1-0077-vddd
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/in_temp_oversampling_ratio
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/subsystem
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/power
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/power/runtime_suspended_time
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/power/autosuspend_delay_ms
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/power/runtime_active_time
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/power/control
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/power/runtime_status
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/dev
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/in_temp_oversampling_ratio_available
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/in_temp_input
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/in_pressure_oversampling_ratio_available
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/in_humidityrelative_input
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/in_pressure_oversampling_ratio
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/in_pressure_input
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/uevent
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/in_humidityrelative_oversampling_ratio
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/name
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/of_node
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/subsystem
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/driver
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/power
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/power/runtime_suspended_time
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/power/autosuspend_delay_ms
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/power/runtime_active_time
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/power/control
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/power/runtime_status
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/modalias
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/uevent
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/name
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/of_node
/sys/bus/i2c/devices/1-0077
I suspect this is what udev will echo...
ls -l /sys/bus/i2c/drivers/bmp280/1-0077
lrwxrwxrwx 1 root root 0 Aug 8 21:20 /sys/bus/i2c/drivers/bmp280/1-0077 -> ../../../../devices/platform/soc/fe804000.i2c/i2c-1/1-0077
So I could set a rule to fe804000.i2c, if so, and that value is consistent. However, looking at the device tree, I can get the sensor name, power state, but not the sensor data. I need the 'in_*_input leaves to get the actual sensor data. That data appears to only be visible under the iio:deviceX tree leaves. Rats.
For example...
# cat /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/name
bme280
# cat /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1/in_temp_input
25390
Meaning, the Celsius temperature is 25.390 per the sensor.
Did find a couple of references to udev and i2c devices...
KERNEL=="i2c-[0-9]*", GROUP="i2c"
And...
[https://github.com/rockowitz/ddcutil/issues/85]
Just hints at what might be possible.
But this does not work...
udevadm info -a -p $(udevadm info -q path -n /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077)
This however lets me at least see the i2c bus, i.e. bus 1, where my devices are connected...
udevadm info -a -p $(udevadm info -q path -n /dev/i2c-1)
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '//devices/platform/soc/fe804000.i2c/i2c-1/i2c-dev/i2c-1':
KERNEL=="i2c-1"
SUBSYSTEM=="i2c-dev"
DRIVER==""
ATTR{name}=="bcm2835 (i2c@7e804000)"
looking at parent device '//devices/platform/soc/fe804000.i2c/i2c-1':
KERNELS=="i2c-1"
SUBSYSTEMS=="i2c"
DRIVERS==""
ATTRS{name}=="bcm2835 (i2c@7e804000)"
looking at parent device '//devices/platform/soc/fe804000.i2c':
KERNELS=="fe804000.i2c"
SUBSYSTEMS=="platform"
DRIVERS=="i2c-bcm2835"
ATTRS{driver_override}=="(null)"
looking at parent device '//devices/platform/soc':
KERNELS=="soc"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"
looking at parent device '//devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
But none of the i2c sensors are under the /dev tree, only the /sys tree?
find /dev | grep 1-0077
(nothing)
find /sys| grep 1-0077
/sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077
Well, the mystery is solved... if I do use udev to make an alias rule it will have to deal with the 'deviceX' issue, likely one rule for each potential X value.
udevadm info -a -p /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/soc/fe804000.i2c/i2c-1/1-0077/iio:device1':
KERNEL=="iio:device1"
SUBSYSTEM=="iio"
DRIVER==""
ATTR{in_humidityrelative_input}=="30116"
ATTR{in_humidityrelative_oversampling_ratio}=="16"
ATTR{name}=="bme280"
ATTR{in_pressure_oversampling_ratio}=="16"
ATTR{in_temp_oversampling_ratio}=="2"
ATTR{in_pressure_input}=="100.482445312"
ATTR{in_temp_oversampling_ratio_available}=="1 2 4 8 16"
ATTR{in_temp_input}=="25890"
ATTR{in_pressure_oversampling_ratio_available}=="1 2 4 8 16"
looking at parent device '/devices/platform/soc/fe804000.i2c/i2c-1/1-0077':
KERNELS=="1-0077"
SUBSYSTEMS=="i2c"
DRIVERS=="bmp280"
ATTRS{name}=="bme280"
looking at parent device '/devices/platform/soc/fe804000.i2c/i2c-1':
KERNELS=="i2c-1"
SUBSYSTEMS=="i2c"
DRIVERS==""
ATTRS{name}=="bcm2835 (i2c@7e804000)"
looking at parent device '/devices/platform/soc/fe804000.i2c':
KERNELS=="fe804000.i2c"
SUBSYSTEMS=="platform"
DRIVERS=="i2c-bcm2835"
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/soc':
KERNELS=="soc"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
The kernel/kernel drivers is/are definitely setting the deviceX references. Hope the Pi gurus can tell me how or why sometimes I see device0 vs device1 references. Below is a device that ended up on device0 branch, not device1 branch...
udevadm info -a -p /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0040/iio:device0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/soc/fe804000.i2c/i2c-1/1-0040/iio:device0':
KERNEL=="iio:device0"
SUBSYSTEM=="iio"
DRIVER==""
ATTR{in_temp_input}=="25844"
ATTR{sampling_frequency_available}=="20 40 70 120"
ATTR{sampling_frequency}=="20"
ATTR{heater_enable}=="0"
ATTR{name}=="htu21"
ATTR{in_humidityrelative_input}=="29220"
ATTR{battery_low}=="0"
looking at parent device '/devices/platform/soc/fe804000.i2c/i2c-1/1-0040':
KERNELS=="1-0040"
SUBSYSTEMS=="i2c"
DRIVERS=="htu21"
ATTRS{name}=="htu21"
looking at parent device '/devices/platform/soc/fe804000.i2c/i2c-1':
KERNELS=="i2c-1"
SUBSYSTEMS=="i2c"
DRIVERS==""
ATTRS{name}=="bcm2835 (i2c@7e804000)"
looking at parent device '/devices/platform/soc/fe804000.i2c':
KERNELS=="fe804000.i2c"
SUBSYSTEMS=="platform"
DRIVERS=="i2c-bcm2835"
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/soc':
KERNELS=="soc"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
This is all interesting. My linux-fu is weak, I've setup volumes etc by uuid and dug deep in some areas but the attribute stuff is new to me, my google-fu usually sees me through but can get copy an paste happy, only just actually understanding overlays (first played with android custom builds). I need to explore the symlinks further as I wonder if there isn't an easier way, but the in_temp etc is the obvious way to find the path combined with known i2c address. I've had to drop the iioDevice idea because most of my sensors don't use that folder scheme.
I often see failures on first i2c read but retry usually solves, do you always have to reset i2c bus to get alive again?
NodeRed-wise I'm now thinking of supporting all the possible sensor i2c address combos via overlay and accepting failure of init for most of them, then test/read all and get user to assign position/function of sensor if any doesn't have an existing user association/config.
Yeah, the errors tend to resolve on repeat query, what is odd is my python code, and what I have written using i2c-bus (node) library, rarely has issues. But the current bme280-sensor library for node, does once in a while get Remote IO errors, which seems to be i2c bus access issue, maybe since I often have two or three sensors per bus, they trip each other up at times?
I only need to do a i2c bus reset when I see the bus-scan-slow down issue. The bme280-sensor node library suffers from this, but it is not clear if this is caused by that library or it is a victim of it. I just recently saw the bus-scan-slow down issue using multiple dtoverlays concurrently, using several sensors on the same bus. Which suggests the issue is in i2c bus low level code. Doing a i2cdetect CLI command can expose this bus slow down as well when it is active. The following thread (https://www.raspberrypi.org/forums/viewtopic.php?t=203152) in the Pi forum suggests this slow down is cause by a wiring fault.. but I know for a fact that is not the only cause given the testing and experience I have had.
I don't have a good way to do a bus reset from code/scripting at this time, only a OS reboot seems to clear the issue consistently when I discover it.
Ah that's a useful link, thanks, I wonder if conflicting strength pull-up resistors could be at play, an I read a ton on the i2c clocking issue before which seems a red herring. Have you seen/tested the slow down on i2cdetect like it mentions?
Keen to know what sensors are you using, and which version (brand/model/revision etc of breakout board), maybe we can rule out with the datasheets/schematic help...
Sure... Adafruit bme280, various generic bme280 boards (from ebay). Adafruit MCP9808. Various SHT3X variants from various sources. Various bmp280 boards. I also have seen it with various PCF8574 based boards, on the bus with the above. When I do see it seems more frequent the more devices I have on the same bus.
Unfortunately, being hobbyist, I don't have a complete test bed, no scope. But my hunch is if someone can scope this, they will see exactly what the deal is.
I did communicate my finds with the author of the bme280-sensor library, and he said he was going to research more into this as well.
The more I read about i2c behavior the more I think this is a bus sharing issue in some part, but I could be wrong. I have, it is rare, even seen the slow down with only one device on the bus, adafruit bme280, which I see as the higher quality board. So there maybe more than one scenario that triggers the issue, which would explain why others have suggested few different reasons that result in the same symptom.
This thread has stretched a bit... but I wanted to include an example of how, at least, I handled the iio:device path variance. This is not pretty but works. I did this as mostly flow based versus function code based, since I think a flow illustrates the issue better than a block of code.
[{"id":"48105e0e.92b4f","type":"file in","z":"7a148091.0b1138","name":"BME280 Temperature (C)","filename":"","format":"utf8","chunk":false,"sendError":false,"x":930,"y":80,"wires":[["714f8961.85d28"]]},{"id":"2ba84a21.a9c486","type":"fs-ops-access","z":"7a148091.0b1138","name":"Device?","path":"path","pathType":"msg","filename":"temperature","filenameType":"msg","read":true,"write":false,"throwerror":false,"x":580,"y":120,"wires":[["7bfe2924.a918f8"],["7971c52b.7550dc"]],"outputLabels":["Accessible","Error"]},{"id":"1e46d0ed.43c177","type":"function","z":"7a148091.0b1138","name":"Path","func":"msg.path = `/sys/bus/i2c/devices/${msg.bus}-00${msg.address}/iio:device${msg.device}`\n\nmsg.pressure = `in_pressure_input`;\nmsg.temperature = `in_temp_input`;\nmsg.humidity = `in_humidityrelative_input`;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":430,"y":120,"wires":[["2ba84a21.a9c486"]]},{"id":"1f9f4e2e.51e96a","type":"counter-loop","z":"7a148091.0b1138","name":"Devices","counter":"device","counterType":"msg","reset":true,"resetValue":"value-null","initial":0,"initialType":"num","operator":"lt","termination":"devices","terminationType":"msg","increment":1,"incrementType":"num","x":280,"y":100,"wires":[[],["1e46d0ed.43c177"]]},{"id":"651f5a34.cae20c","type":"debug","z":"7a148091.0b1138","name":"Message","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1160,"y":360,"wires":[]},{"id":"9df2af77.7718b","type":"inject","z":"7a148091.0b1138","name":"Automatic","props":[{"p":"devices","v":"2","vt":"num"},{"p":"address","v":"77","vt":"num"},{"p":"bus","v":"1","vt":"num"}],"repeat":"900","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":110,"y":100,"wires":[["1f9f4e2e.51e96a"]]},{"id":"7bfe2924.a918f8","type":"function","z":"7a148091.0b1138","name":"File","func":"msg.filename = `${msg.path}/${msg.temperature}`\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":730,"y":80,"wires":[["48105e0e.92b4f"]]},{"id":"714f8961.85d28","type":"function","z":"7a148091.0b1138","name":"Trim","func":"msg.temperature = msg.payload.trim();\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":1130,"y":80,"wires":[["1c01b1da.03b53e"]]},{"id":"ce4886e4.fe0598","type":"file in","z":"7a148091.0b1138","name":"BME280 Pressure (kPa)","filename":"","format":"utf8","chunk":false,"sendError":false,"x":790,"y":180,"wires":[["ce797f1e.331ad8"]]},{"id":"2b4e0285.6e8a16","type":"function","z":"7a148091.0b1138","name":"File","func":"msg.filename = `${msg.path}/${msg.pressure}`\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":430,"y":220,"wires":[["b106670a.a338a8"]]},{"id":"ce797f1e.331ad8","type":"function","z":"7a148091.0b1138","name":"Trim","func":"msg.pressure = msg.payload.trim();\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":990,"y":180,"wires":[["c2b4d249.95a0a"]]},{"id":"1e82ed5f.9f875b","type":"file in","z":"7a148091.0b1138","name":"BME280 Relative Humidity (%)","filename":"","format":"utf8","chunk":false,"sendError":false,"x":810,"y":280,"wires":[["11378ae8.48160d"]]},{"id":"6373aa2d.b3614c","type":"function","z":"7a148091.0b1138","name":"File","func":"msg.filename = `${msg.path}/${msg.humidity}`\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":430,"y":320,"wires":[["63f6c549.682544"]]},{"id":"972554ec.531b98","type":"function","z":"7a148091.0b1138","name":"Trim","func":"msg.humidity = msg.payload.trim();\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":870,"y":360,"wires":[["208d98c6.ef24"]]},{"id":"208d98c6.ef24","type":"function","z":"7a148091.0b1138","name":"Delete","func":"delete msg.filename;\ndelete msg.devices;\ndelete msg.path;\ndelete msg.payload;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":1010,"y":360,"wires":[["651f5a34.cae20c"]]},{"id":"5b8367bb.5121f","type":"file in","z":"7a148091.0b1138","name":"HTU21D Temperature (C)","filename":"","format":"utf8","chunk":false,"sendError":false,"x":930,"y":480,"wires":[["9d498f2b.33aaa"]]},{"id":"4c66e779.c093e","type":"fs-ops-access","z":"7a148091.0b1138","name":"Device?","path":"path","pathType":"msg","filename":"temperature","filenameType":"msg","read":true,"write":false,"throwerror":false,"x":580,"y":520,"wires":[["7aa968a2.2a955"],["d8a270ac.8492f8"]],"outputLabels":["Accessible","Error"]},{"id":"a818a846.389c3","type":"function","z":"7a148091.0b1138","name":"Path","func":"msg.path = `/sys/bus/i2c/devices/${msg.bus}-00${msg.address}/iio:device${msg.device}`\n\nmsg.pressure = `in_pressure_input`;\nmsg.temperature = `in_temp_input`;\nmsg.humidity = `in_humidityrelative_input`;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":430,"y":520,"wires":[["4c66e779.c093e"]]},{"id":"1f0c438e.e3c874","type":"counter-loop","z":"7a148091.0b1138","name":"Devices","counter":"device","counterType":"msg","reset":true,"resetValue":"value-null","initial":0,"initialType":"num","operator":"lt","termination":"devices","terminationType":"msg","increment":1,"incrementType":"num","x":280,"y":500,"wires":[[],["a818a846.389c3"]]},{"id":"93d1aa47.e2b828","type":"debug","z":"7a148091.0b1138","name":"Message","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1160,"y":760,"wires":[]},{"id":"2c57cd58.a1dcea","type":"inject","z":"7a148091.0b1138","name":"Automatic","props":[{"p":"devices","v":"2","vt":"num"},{"p":"address","v":"40","vt":"num"},{"p":"bus","v":"1","vt":"num"}],"repeat":"900","crontab":"","once":true,"onceDelay":0.1,"topic":"","x":110,"y":500,"wires":[["1f0c438e.e3c874"]]},{"id":"7aa968a2.2a955","type":"function","z":"7a148091.0b1138","name":"File","func":"msg.filename = `${msg.path}/${msg.temperature}`\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":730,"y":480,"wires":[["5b8367bb.5121f"]]},{"id":"9d498f2b.33aaa","type":"function","z":"7a148091.0b1138","name":"Trim","func":"msg.temperature = msg.payload.trim();\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":1130,"y":480,"wires":[["5f94fcaf.4bba34"]]},{"id":"52e3b55d.5df5d4","type":"file in","z":"7a148091.0b1138","name":"HTU21D Pressure (kPa)","filename":"","format":"utf8","chunk":false,"sendError":false,"x":790,"y":580,"wires":[["41de6d0e.be04cc"]]},{"id":"41ba7303.c0b2cc","type":"function","z":"7a148091.0b1138","name":"File","func":"msg.filename = `${msg.path}/${msg.pressure}`\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":430,"y":620,"wires":[["4288f39a.8f3bac"]]},{"id":"41de6d0e.be04cc","type":"function","z":"7a148091.0b1138","name":"Trim","func":"msg.pressure = msg.payload.trim();\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":990,"y":580,"wires":[["3987be43.0aa0fa"]]},{"id":"7c7dcfb6.c3a7e","type":"file in","z":"7a148091.0b1138","name":"HTU21D Relative Humidity (%)","filename":"","format":"utf8","chunk":false,"sendError":false,"x":810,"y":680,"wires":[["e9c03442.ba7af"]]},{"id":"b4594e2c.2cbb28","type":"function","z":"7a148091.0b1138","name":"File","func":"msg.filename = `${msg.path}/${msg.humidity}`\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":430,"y":720,"wires":[["7614797a.cb938"]]},{"id":"d44e3d7f.f638b8","type":"function","z":"7a148091.0b1138","name":"Trim","func":"msg.humidity = msg.payload.trim();\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":870,"y":760,"wires":[["37b44e28.018962"]]},{"id":"37b44e28.018962","type":"function","z":"7a148091.0b1138","name":"Delete","func":"delete msg.filename;\ndelete msg.devices;\ndelete msg.path;\ndelete msg.payload;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":1010,"y":760,"wires":[["93d1aa47.e2b828"]]},{"id":"4288f39a.8f3bac","type":"fs-ops-access","z":"7a148091.0b1138","name":"Device?","path":"path","pathType":"msg","filename":"pressure","filenameType":"msg","read":true,"write":false,"throwerror":false,"x":580,"y":620,"wires":[["52e3b55d.5df5d4"],["cc1618a.320a2e8"]],"outputLabels":["Accessible","Error"]},{"id":"7614797a.cb938","type":"fs-ops-access","z":"7a148091.0b1138","name":"Device?","path":"path","pathType":"msg","filename":"humidity","filenameType":"msg","read":true,"write":false,"throwerror":false,"x":580,"y":720,"wires":[["7c7dcfb6.c3a7e"],["e74f9ff8.1df098"]],"outputLabels":["Accessible","Error"]},{"id":"cc1618a.320a2e8","type":"function","z":"7a148091.0b1138","name":"Delete","func":"delete msg.error;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":730,"y":640,"wires":[["86cb1f8c.59594"]]},{"id":"e74f9ff8.1df098","type":"function","z":"7a148091.0b1138","name":"Delete","func":"delete msg.error;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":730,"y":740,"wires":[["d44e3d7f.f638b8"]]},{"id":"b106670a.a338a8","type":"fs-ops-access","z":"7a148091.0b1138","name":"Device?","path":"path","pathType":"msg","filename":"pressure","filenameType":"msg","read":true,"write":false,"throwerror":false,"x":580,"y":220,"wires":[["ce4886e4.fe0598"],["8ea80c68.025068"]],"outputLabels":["Accessible","Error"]},{"id":"8ea80c68.025068","type":"function","z":"7a148091.0b1138","name":"Delete","func":"delete msg.error;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":730,"y":240,"wires":[["4410042d.86b23c"]]},{"id":"63f6c549.682544","type":"fs-ops-access","z":"7a148091.0b1138","name":"Device?","path":"path","pathType":"msg","filename":"humidity","filenameType":"msg","read":true,"write":false,"throwerror":false,"x":580,"y":320,"wires":[["1e82ed5f.9f875b"],["5816efca.3bd488"]],"outputLabels":["Accessible","Error"]},{"id":"5816efca.3bd488","type":"function","z":"7a148091.0b1138","name":"Delete","func":"delete msg.error;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":730,"y":340,"wires":[["972554ec.531b98"]]},{"id":"3987be43.0aa0fa","type":"link out","z":"7a148091.0b1138","name":"","links":["fd5d6982.7519c8"],"x":1095,"y":580,"wires":[]},{"id":"fd5d6982.7519c8","type":"link in","z":"7a148091.0b1138","name":"","links":["3987be43.0aa0fa","86cb1f8c.59594"],"x":335,"y":720,"wires":[["b4594e2c.2cbb28"]]},{"id":"c2b4d249.95a0a","type":"link out","z":"7a148091.0b1138","name":"","links":["ea446787.221ff8"],"x":1095,"y":180,"wires":[]},{"id":"ea446787.221ff8","type":"link in","z":"7a148091.0b1138","name":"","links":["c2b4d249.95a0a","4410042d.86b23c"],"x":335,"y":320,"wires":[["6373aa2d.b3614c"]]},{"id":"4410042d.86b23c","type":"link out","z":"7a148091.0b1138","name":"","links":["ea446787.221ff8"],"x":835,"y":240,"wires":[]},{"id":"86cb1f8c.59594","type":"link out","z":"7a148091.0b1138","name":"","links":["fd5d6982.7519c8"],"x":835,"y":640,"wires":[]},{"id":"1c01b1da.03b53e","type":"link out","z":"7a148091.0b1138","name":"","links":["2809b6ec.e47d8a"],"x":1235,"y":80,"wires":[]},{"id":"2809b6ec.e47d8a","type":"link in","z":"7a148091.0b1138","name":"","links":["1c01b1da.03b53e"],"x":335,"y":220,"wires":[["2b4e0285.6e8a16"]]},{"id":"5f94fcaf.4bba34","type":"link out","z":"7a148091.0b1138","name":"","links":["aa34000f.bd5b4"],"x":1235,"y":480,"wires":[]},{"id":"aa34000f.bd5b4","type":"link in","z":"7a148091.0b1138","name":"","links":["5f94fcaf.4bba34"],"x":335,"y":620,"wires":[["41ba7303.c0b2cc"]]},{"id":"6b5c9f5.1330ce","type":"link out","z":"7a148091.0b1138","name":"","links":["114e1674.dede5a"],"x":835,"y":140,"wires":[]},{"id":"114e1674.dede5a","type":"link in","z":"7a148091.0b1138","name":"","links":["6b5c9f5.1330ce"],"x":155,"y":60,"wires":[["1f9f4e2e.51e96a"]]},{"id":"6a183133.a4be7","type":"link out","z":"7a148091.0b1138","name":"","links":["4212cf1f.a2923"],"x":835,"y":540,"wires":[]},{"id":"4212cf1f.a2923","type":"link in","z":"7a148091.0b1138","name":"","links":["6a183133.a4be7"],"x":155,"y":460,"wires":[["1f0c438e.e3c874"]]},{"id":"4f7db0a1.fabd1","type":"link in","z":"7a148091.0b1138","name":"","links":["e9c03442.ba7af"],"x":755,"y":780,"wires":[["d44e3d7f.f638b8"]]},{"id":"e9c03442.ba7af","type":"link out","z":"7a148091.0b1138","name":"","links":["4f7db0a1.fabd1"],"x":995,"y":680,"wires":[]},{"id":"11378ae8.48160d","type":"link out","z":"7a148091.0b1138","name":"","links":["653f027f.a3b254"],"x":995,"y":280,"wires":[]},{"id":"653f027f.a3b254","type":"link in","z":"7a148091.0b1138","name":"","links":["11378ae8.48160d"],"x":755,"y":380,"wires":[["972554ec.531b98"]]},{"id":"d8a270ac.8492f8","type":"function","z":"7a148091.0b1138","name":"Delete","func":"delete msg.error;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":730,"y":540,"wires":[["6a183133.a4be7"]]},{"id":"7971c52b.7550dc","type":"function","z":"7a148091.0b1138","name":"Delete","func":"delete msg.error;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":730,"y":140,"wires":[["6b5c9f5.1330ce"]]}]
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
