This was exactly what I needed thanks! - I was struggling to work out why it worked in older version and this was the info I needed :) (It was quite a gap between when I last used the system)


Some sort of unique 'session identifier' would be useful as well - at the moment I have to manually rename my captured files to insert a string like "_Session_211007_" so that I can use the batch processing in pixinsight to match flats to multi night sessions.

The using some post-processing to insert current date runs into problems where the imaging session starts pre-midnight and goes on till the early hours of the next day, so you end up with 2 dates for 1 session which makes automation hard.

Using the date of when Ekos/Kstars started would be OK but there might be the case where there is a crash or user restart which might cause a issue.(perhaps use the start date and only change that to date+1 is it is older than 12 hours say?)

I'm sure there is some way of automating it? I almost went down the route of writing a script but my skills for doing that arn't robust enough to trust I wouldn't lose data etc :)


Yep - what Scott said basically.  I run with a formula from here and combine that with a RG15 for rain detection - I then combine that into a web server response that matches the weather watcher requirements fo Ekos can pick up the weather from my weatherstation. 

float correct_sky_temp(float Ta, float Ts) {
float Tsky = (K1 / 100) * (Ta - K2 / 10) + (K3/100) * pow(exp(K4/1000*Ta),(K5/100));
Tsky = Ts - Tsky;
if(debug_Td) {
              Serial.print("Ts: ");
              Serial.print(" Ta: ");
              Serial.print(" Corrected: ");
  return Tsky;

I just monitor the max/min sky temperature (saved regularly to persist over power cycles / crashes) and then map that to 0-100% cloud cover:

float cloud_cover = (map(sky_temp*100,cloud_min*100,cloud_max*100,0.00,10000)/100);


Are you sure it's circuit related?, my thinking (but without seeing the code) is it's interrupt related and you are being swamped with interrupt requests due to the high level of rainfall resulting in the watchdog being triggered on the ESP8266.

Anyway, here's how to try and see what's causing the crash if it is software related:

If you don't get the crash with low / no rain, it's unlikely to be the circuit. Your increase in resister for the pull up will only come in to play if the distance between the sensor and controller is very long and your wire is quite thin and that would result in missed activations not increased / crashes. You can test this by disconnecting the RG11 unit and manually joining the wires together to simulate a pulse from the RG11 relay.
If you disconnect the RG11, does the ESP still crash? What does it output on the serial port?

I have a RG15 and it can be sensitive to the input voltage causing brownouts, but that would be unlikely to lock up your ESP as it's a separate unit but should't be ruled out just yet though 2A should be more than enough for both devices to co-exist.. (RG11 is 55mA max @12V input with everything on from the datasheet)

Do you have a link to the code you are running?


This is excellent - well done!


I think this has been asked before - I have a memory that the work around might be to create a LRGB sequence of 1 exposure per filter then repeat that using the options in the scheduler (repeat for X runs or repeat until options maybe ?)
Problems to look out for are if your filters are not par-focal you will be spending a lot of time focusing between exposures...