hdutton

7 hours ago, skybadger said:

Two things, you don't need the sensor driver, you could call ascom directly from your sensor controller using the ascom rest api. I'm using node red to run a workflow that is called by Alexa, it receives data from sensors and can issue REST calls into Ascom to open and close the dome etc.

Second, average is easy and not that intensive, you just need to add the data as the buffer fills and then manage adding and deleting once full.

 

First, let me say that this project was a quick and dirty exercise in how fast I could get it done.  I don't even use CSEP...

I'm not following point 1 though. 

• What is a "sensor driver".  A driver in my mind is a library/code to access a given sensor device.  You need that (even if it is "client side".)
• What is a "sensor controller".  Is this the Micro-controller (Mega2560 or UNO in this case)?
• Sounds like you're saying that you don't need an ASCOM driver that the Micro-controller is sending data to ASCOM but my understanding of ASCOM says that's not how it works. 
• An ASCOM driver talks to the Microcontroller that talks to the sensors.

I'm not really interested in working on CSEP again but rather just want to understand if this is something worth looking into for my other projects or not.

Are the sensors attached... it doesn't obey that setting except...

Wow, the list of sensors really goes on forever.  Arduino is very popular so lots of library support. 

I like to stick with I2C since it travels some distance with little trouble and two pins take care of everything.  I use all of the following in one role or another:

BME280, SI7021, MLX90614, BMP180, DS18B20 (1-wire)

It's been an age since I've touched this code.  Provided your configuration and hardware are good the only thing that comes to mind would be if Chart.min.js was updated and is no longer functioning as intended with my code.

Github can be used to download an older version (from any repository) or grab the fork I made from about two years ago and try that...

https://github.com/hjd1964/Chart.js

Well, I attached the image file instead:

Here's what the web monitor looks like.  Sorry, no fancy real data... I'm just building the hardware now so it's inside.

I wanted to stop by and let folks know that the CloudSensorEvoPlus -Alpha on my GitHub (https://github.com/hjd1964/CloudSensorEvoPlus/tree/alpha) now has support for the Arduino Ethernet Shield (W5100).  This displays a chart of the last half-hour (actually the time span is configurable) of cloud readings along with the sensor data and safety status.   It also has support for reporting on barometric pressure (BMP180) and humidity (HTU21D.)  This is in addition to the usual serial channel that's usually tied up with the ASCOM driver.  There's also a command channel on port 9999 of the ethernet adapter so "anyone" can stop by and pick-up a sensor reading.

Full function requires a Arduino Mega2560.  However, the cloud detection w/web-site will run on a Mega328 (UNO, etc.) if you leave the humidity and barometric pressure sensing turned off.

Howard

I hardly believe the code is the problem... if you use the latest code on hdutton's github, it should work.

What kind of hardware do you use? Maybe you have the links to the supplier?

Your cloud and rain sensor behaves exactly as mine, when there was i wire connected wrong, or some sensor not responded etc. 

Can you take a picture of your hardware?

I actually got mine working again, even though it was totally drenched in water. i have now sealed the box even more (wish me luck) and it is up and running again

I totally agree, I doubt the code is the problem too... but this debugging exercise can probably identify the problem causing device attached.

This firmware really needs a once over to make it more "robust" against component failures... if something stops working it shouldn't silently fail or hang the device....  I probably will revisit this aspect one day, but my hobby time is spread very thin for now.

I'll be away this weekend but we're getting somewhere...

That "." should print once a second, over and over.  the stuff between the braces {} as follows

void loop(void)

{

};

in the program gets run one line after another, over and over,  except the stuff in the "if" statement braces is blocked from running for all but once time a second (generally.)  

Next step will be moving the

Serial.print(".");

you just added down in the sequence of statements until you don't see the "." print.  What ever line in the code that's then immediately above it caused the program to lock.

Just add it as indicated below:

  // gather data from sensors once a second
  if ((now%1000==0) && (last!=now)) {
    Serial.print(".");

    last=now; // blocks calling more than once during the same ms

 

Weird, it's getting hard to believe that it's not responding to the :IP# command, you did hit Enter or the send button yes?

Did you try adding that line println() as shown below, need this to see if we returned from the init_MLX90614();  function:

void setup(void)
{
  Serial.begin(9600);

  init_DS18B20();
  init_MLX90614();

  Serial.println("Init. Done.");
}
 

My next step would be to put a Serial.print("."); within the main loop so it prints once a second to see that the processor made it there.

It can take persistence, but there is a reason why it's working and it can be found, if taken step by step.

Maybe it's not coming back from the MLX90614 init.

Another good check is that it returned from the MLX90614 init.  change the setup() function to add the println as shown below:

void setup(void)
{
  Serial.begin(9600);

  init_DS18B20();
  init_MLX90614();

  Serial.println("Init. Done.");
}
 

Well, so much for my first guess.  There was an obvious potential for an infinite loop in the DS18B20 init. code.

Next guess would be one of these lines:

    ds18b20_celsius = read_DS18B20();
    MLX90614_celsius = read_MLX90614();
 

If you could add // before both of these lines to comment them out and run again.  You'll have send :IP# to see if it's working.  If it works then try them one at a time to see which one did it.

Ok, so we now know that something's wrong with the Nano/hardware/firmware somewhere.  I'm assuming that it's compiling correctly...

It's probably getting hung up in initialization somewhere....

You could do some spying on what's going on by un-commenting the following lines in CloudSensorEvoPlus:

//  Serial.println("Initializing DS18B20 sensor...");

//  Serial.println("Initializing MLX90614 sensor...");

Just remove the // part and upload again.  You can't use my ASCOM driver when these lines are enabled but they will provide some feedback from the serial monitor.  For, example if the DS18B20 message comes up but not the MLX90614 then it's getting stuck trying to find the DS18B20 (my guess.)

Howard

Hi Daniel,

Sorted the arduino issue and have uploaded the programme and it shows the command tab. 

Connected the Arduino nano and opened Maxpilote to setup properties, arduino nano set on 

com port 11.

Error.png

Any ideas to why this should happen?

Sorry for being a pain........

Steve

You're not getting a connection to the Arduino nano, which is indicated by the "Error" status.  This can be caused by the serial port being inaccessible for some reason (in use elsewhere) or because the device didn't respond with the proper identification when asked.

You can verify that the firmware is alive and more or less functioning on the Nano by using the serial monitor button in the upper right corner of the Arduino environment.  Issue the :IP# command to see if it's there.  If it responds with "CloudSensorEvoPlus" you it should be able to connect and the nano will likely not be the cause of your problem here.  I'll keep an eye out here for a bit until you're (hopefully!) up and running.

Howard

No problem, I've removed the readme for now.

Murphy's law at work, there's no knowing when it'll strike.

I'm not 100% up on what's going on in that i2cmaster library, but it looks to me like you're trying to use the soft I2C (which supports any Arduino pins.)  It probably requires the user to #define what pins the library will use and so throws a fit if that info. isn't found.

I think this is probably not the i2cmaster library you want to use, a successful compile here on Arduino 1.6.5 starts like this:

Using library OneWire in folder: C:\Users\Howard\Documents\Arduino\libraries\OneWire
Using library i2cmaster in folder: C:\Users\Howard\Documents\Arduino\libraries\i2cmaster (1.0.x format)
Using library SPI in folder: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI

C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10605 -DARDUINO_AVR_MEGA2560 -DARDUINO_ARCH_AVR -IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino -IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\mega -IC:\Users\Howard\Documents\Arduino\libraries\OneWire -IC:\Users\Howard\Documents\Arduino\libraries\i2cmaster -IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI C:\Users\Howard\AppData\Local\Temp\build3967002890531707230.tmp\CloudSensorEvoPlus.cpp -o C:\Users\Howard\AppData\Local\Temp\build3967002890531707230.tmp\CloudSensorEvoPlus.cpp.o
 

I have updated the Read Me with instructions how to set the threshold sliders and a picture of the setup dialog.

/Daniel

Cloud Sensor Evo Plus.doc

Nice to hear that things are working so far.  I'll upload the the new readme to GitHub later today.

The information you created here really ties everything together.  I didn't know the cheap eBay rain sensor existed and I'll be adding one to my (half started project) weather station.

I reversed the rain sensor logic in the ASCOM driver, update and let me know if that does it.

Well, that explains it, their amp. must invert the output.  I expected the thing to conduct more when wet and the output to go up, it goes down.  I'll reverse it, no problem.

I'm thinking firmware issue or the hardware is really returning that value...

You updated to the firmware I posted earlier today?  Even if you didn't, the rain sensor value shouldn't go to (100%.)

The :Gr# command should return a number between 0.0 and 1.0, if the sensor is dry more toward 0.0 if wet more toward 1.0  Try this and let me know,

If every thing is working, a (100%) value indicates that the input is at maximum, at or above 5V?

This is the one sensor input that actually kind of works here... the open input floats up and down at around (24%) on my Arduino.

I also just added reporting of the rain sensor value (in %) to the ASCOM driver too.  That should help with tuning the raining safety trigger.

Take care,

Howard

The 10bit ADC of the Arduino returns a value of 0 to 1023.  I do a little math on it and turn that into a floating point number of 0.0 to 1.0 which is then passed to the ASCOM firmware when requested (:Gr#).  For the dry slider, if rain sensor value is < the dry setting the indication is dry.  For the wet slider, if rain sensor value (0 to 1 = 0 to 100%) is > the wet slider the indication is raining (which is also unsafe.)  Anything between gives a damp indication.

[so to get "Dry", i had to move the slider all the way up to 100%, otherwise it was "raining"]

The dry slider should never be above the wet slider.  Probably you didn't have the wet slider far enough to the right. 

I just updated the ASCOM driver automatically keep dry thresholds below wet thresholds since it should always be that way.

Glad you like, enjoy.

Howard