DO GPIO polling - unsure of existing capability

[ikeysolomon]

As of late i have been on a flurry of adding sensors to my rig.

The latest is a FC-37 Rain sensor. This has a digital output to GPIO. Albeit merely a 1 or 0. What i would like to know is there any scope to open up the current polling of sensors up to also DO GPIO? If it isnt already?

Apologies if it is and I cant see the right way of doing it. I would be willing to help establish this with a crap PR to you that you could polish further.

Extending on this i have thought, how would you feel about a *.replace() function being made available in the overlay input?
With this capability one could poll a rain sensor and then do something like *.replace(0,"Raining").replace(1,"Not raining"). I would also be willing to help in this regard also.

Kind Regards,
Sam

[aaronwmorris]

It's possible to use rpi.gpio or gpiozero to read the state of pins. It makes the sensor Raspberry Pi specific and we could mark it as such.

The current challenge is there are no sensor slots left in the User Sensors to assign the Rain sensor. I will have to work on making more sensor slots available.

As for the replace, that would not be necessary. I would just create a lookup table dictionary in indi_allsky/constants.py . Something like

RAIN_MAP_STR = {
    0 : 'No Rain',
    1 : 'Raining',
}

Then you can dedicate an overlay variable that looks up that dictionary:

rain_sensor_value = self.sensors_user_av[constants.SENSOR_USER_RAIN_SENSOR]  # float

# use round() to cast to an int
rain_overlay_variable = constants.RAIN_MAP_STR[round(rain_sensor_value)]

[ikeysolomon]

G'day Aaron,

That would be awesome if you could do that. There is obviously scope for Indi-allsky to take on a weather station role as well as image generation. Understanding that I have an ultimate hope of using all this generated data in proactive way to eventually send alerts. The obvious low hanging fruit here is to just use MQTT. Therefore, whatever approach is taken to convert DO signals might be best placed before things are sent to MQTT if that would at all be possible? If not then such as life, as long as its marked as a Rain sensor figuring it out after the fact is a no-brainer.

Further towards this aim, how would you also feel about another derived value? The number of stars could be seen as a surrogate marker of cloud cover. An imposed constraint of using stars in this way, might be that stars first have to reach n= 100 or something and then if they drop sequentially downwards then you get something like:

Star count
0-30 = High Cloud
31-65 = Moderate Cloud
66-100 = Light Cloud

Food for thought.

Back to my end idea I am thinking that I could use the data to come up with a two-alert system. I am very much a miser and anything that could proactively help warn me to drag the telescope under cover would be gold.

Boolean alerts straight away
Lightning (under 10km) and rain

Probabilistic model of warning = Rain likely or Rain Imminent
Humidity, Pressure, Dew Point, Cloud Cover

Thanks for getting back to me,
Kind Regards,

Sam

[ikeysolomon]

Just did a quick test of the existing infrastructure in indi it seems when I attribute D17 in sensors thats enough to 'hold' the sensor but obviously the system doesn't interpret what's coming from it.

I tried polling in a terminal myself with a command and the output looks the above is happening ^