Hi Howard,
I’m building an Allsky just next to OCS, from time to time the camera under the dome will need some heating when humidity and temperature reach a certain level. An idea has crossed my mind that would be the possibility with OCS to give the sensor values to avoid installing new sensors. As OCS is a webserver i thought it would be possible to generate an xml output when a request is sent from a client. I really don’t know the effort  that would be necessary to make this but the idea seems interesting to me. I know how to program a small board (nano, micro) with a simple web client page, collect parameters from a webserver with actions to launch.
It is not a demand but a question as I know you are very busy with Onstep environment we are all enjoying.

Thanks in advance for your answer 
koal01

I have made the modification and it works as I wish now.
Thanks

Running full OCS on a ESP32 would be terrific, this MCU is cheap and fast.
Would you intend to build a PCB based on the ESP32, the 38 pin version i suppose,  with selected features (as the Mini in your OnStep project) or would this ESP32 cover all the current features in OCS ?
Any way i'll follow this project and it will be a pleasure to test, i'm avalaible.

Thank you
Koal01

On Fri, Feb 26, 2021 at 07:21 AM, koal01 wrote:

In the future is there any wifi integration in your roadmap on OCS ?
I'm building a second OCS wich would be a nomad version mainly to get the weather webpage.
I was wondering if using few pins, a portable version on a teensy would be possible ?

No plans for the Teensy but adding the capability to run the OCS on the ESP32 has crossed my mind.
The Ethernet webserver in the OCS is a mirror of the ESP8266/ESP32 WiFi, not exactly the same, but close.

On Fri, Feb 26, 2021 at 07:21 AM, koal01 wrote:

By the way my sedentary OCS is very solid, months without any crash, great !

That's what I want to hear.

Yes that capability is in the OCS.ino file...

Probably should make it something you setup in Config.h since the need to do so comes up quite often.

Sorry I should have looked first at the this forum where this issue was already reported and answered...

Hello,
All my relay outputs are high when not activated, and turn low when activated. Is it normal? Can it be set the other way round?

Hi Howard,
In the future is there any wifi integration in your roadmap on OCS ?
I'm building a second OCS wich would be a nomad version mainly to get the weather webpage.
I was wondering if using few pins, a portable version on a teensy would be possible ?

By the way my sedentary OCS is very solid, months without any crash, great !


Thank you
Koal01

On Thu, Dec 24, 2020 at 02:09 PM, Zoltán Pásztor wrote:

Is there any chance in the future any slave mode or connecting to the OnStep?
I'm thinking about close the roof after parking, and open before unpark. And parking on a safety closing.
Is this an ASCOM function, or other?

I will given adding this feature consideration at some point.

Hi!

Is there any chance in the future any slave mode or connecting to the OnStep?
I'm thinking about close the roof after parking, and open before unpark. And parking on a safety closing.
Is this an ASCOM function, or other?
I didn't find any astrophotography acquisition software that make this.

On Thu, Sep 3, 2020 at 03:55 AM, Howard Dutton wrote:

I will come back to the OCS and look into incorporating this and other suggestions/fixes.

This time has arrived.

All suggested changes/fixes are addressed in the code but untested.  I expect it'll all just work.
Some of these changes are kept disabled by default and must be enabled in Constants.h

I added the cup anemometer example code to the OCS on github.  The example code is functionally identical to what's below (compiles to the exact same thing) but the names of variables etc. were changed from RPM to PPM (pulses per minute) in an attempt to avoid some confusion.

On Sun, Dec 20, 2020 at 01:24 PM, Howard Dutton wrote:

The # of switches is irrelevant.  I was going to change the wording in the code comments but that just makes the subject even more confusing so I'm leaving it as is.  Instead imagine the mechanics make one LOW/HIGH event per rotation, even if they don't.

This is the reason it's 0.015 not 0.03.  Two switches, twice as many pulses for a given wind speed so the multiplier is 1/2 as much.

Well, I find this calculator: https://www.calctown.com/calculators/rpm-to-linear-velocity
So, with 80mm "anemometer arm" radius (measured at now) => 120 RPM gives 1 m/s. This is OK, because that gives the 2 revolution per second.

120 RPM = 3,6 km/h => RPM2KPH = 0,03

If I'm correct, this is my number.

The # of switches is irrelevant.  I was going to change the wording in the code comments but that just makes the subject even more confusing so I'm leaving it as is.  Instead imagine the mechanics make one LOW/HIGH event per rotation, even if they don't.

I see 1M/s = 3.6KPH....

So it seems a 3.6 KPH wind gives 2 full revolutions per second and that would be 4x LOW to HIGH transitions per second.  So a pulse per second from this thing represents 3.6/4 = 0.9 KPH of wind.  And that is 60 RPM = 0.9 KPH.  For an RPM to KPH conversion it's 60 * 0.015 = 0.9.  Guess AnemometerRPM2KPH is 0.015 according to this.  So at 3.6KPH wind this thing makes four pulses per second and my code would count 20 of those events (over 5 seconds) then multiply by 12 (60000/5000 milliseconds) for 240 * 0.015 = 3.6

I'm 100% sure in the real world this thing will have fairly large errors and a better number will likely be some not insignificant % lower than 0.015.

This is the design of the anemometer. 
https://www.thingiverse.com/thing:2523343

There is 2 magnets, so 1 revolution is 2 HIGH events. 
And here is a sentence from the creators notes:

"The perimeter of the circle is 50 centimetres, thus, at a wind speed of 1 meter per second, the anemometer makes 2 full revolutions."

I can't interpret this sentence :) , is this equal whit our calculations?

On Sun, Dec 20, 2020 at 11:27 AM, Zoltán Pásztor wrote:

Is this implementable to the Weather.ino?

The following should work I think.  Just substitute this for the similarly named section/functions (they are just place-holders for the real thing) in Weather.ino

Naturally this logs the average wind speed over the sample period interval (5 seconds) but perhaps one would want a longer average so feel free to change that to 60 seconds or whatever.

// -----------------------------------------------------------------------------------------------------------------
// gets windspeed in kph
// this is for a cup anemometer where each rotation causes an open/close event on a switch (or hall effect transducer)
// the pin below counts the number of logic LOW to HIGH events in a given amount of time to calculate the RPM etc.

#define AnemometerPin 18              // interrupt capable pin
// see https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/
#define AnemometerSamplePeriod 5000L  // in milliseconds
#define AnemometerRPM2KPH 0.086886    // converts from RPM to KPH

volatile unsigned long anemometerTurnsCounter = 0;
unsigned long anemometerWindSpeedKPH = 0;

// return (invalid) if not implemented or if there's an error
double weatherWindspeed() {
  if (!windspeedGood) return invalid;

  static unsigned long anemometerCheckTime = 0;
  long anemometerTimeElapsed = (long)(millis()-anemometerCheckTime);
  if (anemometerTimeElapsed >= AnemometerSamplePeriod) {
    anemometerCheckTime = millis();
    cli();
    long anemometerTurnsCount = anemometerTurnsCounter;
    anemometerTurnsCounter = 0;
    sei();
    // convert RPSP to RPM
    long RPM=anemometerTurnsCount * (60000L/anemometerTimeElapsed);
    anemometerWindSpeedKPH = RPM * AnemometerRPM2KPH;
  }

  if (anemometerWindSpeedKPH < 0 || anemometerWindSpeedKPH > 350) anemometerWindSpeedKPH=invalid;
  return anemometerWindSpeedKPH;
}

void anemometerCount() { anemometerTurnsCounter++; }

bool initWindspeed() {
  attachInterrupt(digitalPinToInterrupt(AnemometerPin), anemometerCount, RISING);
  return true;
}

Perfect. This accuracy is enough, this is not a weather station.
Is this implementable to the Weather.ino?

On Sun, Dec 20, 2020 at 06:43 AM, Zoltán Pásztor wrote:

MPH=RPM*.054; //Estimate

KPH=MPH*1.609;

The formula is a simple multiplier.  I'm sure it isn't accurate and is entirely based on the example sketch you provided.

The 0.054 part someone came up with converts to RPM to MPH.  I just factored in the MPH to KPH constant... but somehow messed it up.

So AnemometerRPM2KPH is supposed to be 0.054 * 1.609 = 0.086886