I really like your project and I was planning to build one bymyself but now I found your and it's really really amazing!!
I have a fixed observatory and this board I think can help me with my project.
Having a vineyard I wold like to log olso weather data.
In my case I wold like to use a POST function to a php file on my server sending the already made string in json, but if the connection was lost, internet problem, server down or any possible reason, I would like to log data inside esp32 and when the connection resume send the data don't sended...it's already done or I need to implement it?
I've seen MQQT, I never used this, at maximum I have a raspbeery 2 to make it like broker, mqqt can save my log olso if connection to internet is lost? I'm poor of MQQT
If you need I'm enought expert with ascom platform driver development
Last question, I' in fixed position, can I set fixed value for gps?
Thank you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
It is easier for the host computer to issue a web request to the controller that then returns a JSON string. For instance http://controller_ip_address/rd would return a JSON string of
see pdf section SEB SERVER on getting a JSON response. Your server would request this at intervals of of your chosing.
MQTT is a good alternative and the controller can be configured to send data to a MQTT broker running on a Pi. If you have a Pi you can use that for data logging and an MQTT broker, then also configure mySQMWEB to run on the Pi and get all the logging and fancy graphs in a browser.
if you are familiar with Node-Red you can also do that.
It does not make any sense putting data storage onto the ESP32. You do not have much memory storage and it would run out quickly. Installing an SD card is not really an option as we need those pins for sensors. Sending the data to a host is the best way of handling the data. Most users in the test group have had their systems for long periods of time with little or no down time on their networks. You should only loose data if your network goes down.
People usually implement this using a Pi which connects to a local network and runs the MQTT broker and also mySQMWEB that grabs stuff from the broker. The controller is configured as a station on the same network, so sends the data to the Broker on the Pi.
The PDF has examples on how to set up configure and test MQTT. It is easy enough to follow along if you have a PC running Windoes, you can install MOSQUITO [an MQTT application][details again in PDF step by step instructions] and then work through the examples to configure the controller and send data to the broker at regular intervals.
Regarding fixed location in gps then yes this could be done in the firmware with a minor change. It is added to the list of features for release 102
regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the reply, for the GPS data, it can be usefull or not, in my case I don't know if is necessary but we never know.
For MQTT yes, I'have already read some about it and maybe I can make a phyton script for read and after send it to my web server, and if the connection don't work I can store on mysql on my pi and when connection will work retry after some minutes. (my hosting is under ddso attack one time for years, but is cheap so it's ok ehehehe)
If, and I repeat, if I found time I'm glad to implement alpaca ascom interface for your board, it can be very useful in the future!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the offer re ASCOM alpaca remote. I know how to do this and have done it for the myFP2ESP WiFi project where the code is already present. It would just be a matter of copying the code.
However this is unlikely to be added to the ySQM+ main controller because with all options enabled, we are already at the memory limit of the ESP32. Adding more code/features to the main mySQM+ controller are unlikely in the near future,
HOWEVER
it would be easy to add ascom alpace to any mySQM+ESP32-Daughter board, trivial really.
Our concept is that the mySQM+ controller is now complete - to add any additional features or
sensors we simply add a mySQMplus Daughter board and transfer additional data [and or controller data] between the two using JSON, ESPNOW or MQTT. Again trivial and cheap to do and software already done and tested and working in the field. This ensures we can add new features and new sensors without touching the hardware and PCB of the mySQM+ main controller. Plenty of examples in the PDF.
Using the extra mySQM+ESP32-Daughter Board sorta future proofs the main controller and we have already used it to add remote sensors such as lighning, UV and 433MHz weather stations.
Regards
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have not seen that and cannot comment on it without seeing the science behind it.
What I can say is that there are many implementations out there of mySQM+ using the sky modelling [which is why we use the MLX sensor] and it does work very very well without the need for any special lens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Stefano
Well I did some research on this and found a bit.
1. real germanium type lenses are very expensive [400+
2. the lenses do cut down the tranmission rate of the ir signal component
3. The lenses may have an uneven response across the IR spectrum
4. there are no real benefits as such because
a. there are no comparative studies down to compare sensors with or without AGAINST a standard measurement - in other words the only tests I could find was against other sensors of the same type or against DHT22 - that in itself is meaningless because DHT22 measures ambient temperature AND is not responsive to IR
b. Some users did use an aluminum sheet angled at 45 degrees so it was measuring reflective IR - again there is a loss involved in efficiency and that loss was never quantified in any meaningful way against a standardised meter for measuring IR, and that loss was never measured across the IR spectrum so there never was a baseline established thus no compensation factor able to be achieved
5. There was some discussion mentioned about FOV and whether the FOW was too large and should somehow be more concentrated. I argue the FOV should be reasonably large - clouds move fast in the sky and before you know it, 5-10min they are overhead - the more warning you get the better, and the modelling being used in mySQM+ is pretty accurate and reliable
In other words, there is a number of questions about the validity. It seems to me that the main reason was exposure of the mlx device to dew/humidity/snow/rain and thus chosing to reflect the IR signals via an angled plate [which then was heated] was their answer. But for me, there are still a lot of unanswered queations as I have pointed out above. I think the jury is still out on this one.
Having said all of that I admire those who tried this and testing their systems etc trying to improve things. We are all trying to do this and make things better for other users out there.
regards
Robert
If one wanted to really to have a relaible and accurate system then I really think it would need to be validated and compared to a real standard instrument capable of measuring IR.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello brownrb!
I really like your project and I was planning to build one bymyself but now I found your and it's really really amazing!!
I have a fixed observatory and this board I think can help me with my project.
Having a vineyard I wold like to log olso weather data.
In my case I wold like to use a POST function to a php file on my server sending the already made string in json, but if the connection was lost, internet problem, server down or any possible reason, I would like to log data inside esp32 and when the connection resume send the data don't sended...it's already done or I need to implement it?
I've seen MQQT, I never used this, at maximum I have a raspbeery 2 to make it like broker, mqqt can save my log olso if connection to internet is lost? I'm poor of MQQT
If you need I'm enought expert with ascom platform driver development
Last question, I' in fixed position, can I set fixed value for gps?
Thank you
Hi
It is easier for the host computer to issue a web request to the controller that then returns a JSON string. For instance http://controller_ip_address/rd would return a JSON string of
{ "sqm":5.08355,"nelm":-
8.568,"ambient":18.250,"humidity":63.5,"dewpoint":11.208,"pressure":1010.31,"irambient":
17.710,"irobject":17.310,"lux":1000.00000,"skystate":1,"cloudcover":100.00,"raining":0,"
rvout":0.00,"rainhour":0.00,"rainday":0.00,"windspd":0.00,"beaufort":0,"winddir":0 }
see pdf section SEB SERVER on getting a JSON response. Your server would request this at intervals of of your chosing.
MQTT is a good alternative and the controller can be configured to send data to a MQTT broker running on a Pi. If you have a Pi you can use that for data logging and an MQTT broker, then also configure mySQMWEB to run on the Pi and get all the logging and fancy graphs in a browser.
if you are familiar with Node-Red you can also do that.
It does not make any sense putting data storage onto the ESP32. You do not have much memory storage and it would run out quickly. Installing an SD card is not really an option as we need those pins for sensors. Sending the data to a host is the best way of handling the data. Most users in the test group have had their systems for long periods of time with little or no down time on their networks. You should only loose data if your network goes down.
People usually implement this using a Pi which connects to a local network and runs the MQTT broker and also mySQMWEB that grabs stuff from the broker. The controller is configured as a station on the same network, so sends the data to the Broker on the Pi.
The PDF has examples on how to set up configure and test MQTT. It is easy enough to follow along if you have a PC running Windoes, you can install MOSQUITO [an MQTT application] [details again in PDF step by step instructions] and then work through the examples to configure the controller and send data to the broker at regular intervals.
Regarding fixed location in gps then yes this could be done in the firmware with a minor change. It is added to the list of features for release 102
regards
Robert
"In my case I would like to use a POST function to a php file on my server sending the already made string in json"
yes, that is probably something that could be done. It is not in there right now, but should not be too difficult to do.
Thank you for the reply, for the GPS data, it can be usefull or not, in my case I don't know if is necessary but we never know.
For MQTT yes, I'have already read some about it and maybe I can make a phyton script for read and after send it to my web server, and if the connection don't work I can store on mysql on my pi and when connection will work retry after some minutes. (my hosting is under ddso attack one time for years, but is cheap so it's ok ehehehe)
If, and I repeat, if I found time I'm glad to implement alpaca ascom interface for your board, it can be very useful in the future!
Thank you for the offer re ASCOM alpaca remote. I know how to do this and have done it for the myFP2ESP WiFi project where the code is already present. It would just be a matter of copying the code.
However this is unlikely to be added to the ySQM+ main controller because with all options enabled, we are already at the memory limit of the ESP32. Adding more code/features to the main mySQM+ controller are unlikely in the near future,
HOWEVER
it would be easy to add ascom alpace to any mySQM+ESP32-Daughter board, trivial really.
Our concept is that the mySQM+ controller is now complete - to add any additional features or
sensors we simply add a mySQMplus Daughter board and transfer additional data [and or controller data] between the two using JSON, ESPNOW or MQTT. Again trivial and cheap to do and software already done and tested and working in the field. This ensures we can add new features and new sensors without touching the hardware and PCB of the mySQM+ main controller. Plenty of examples in the PDF.
Using the extra mySQM+ESP32-Daughter Board sorta future proofs the main controller and we have already used it to add remote sensors such as lighning, UV and 433MHz weather stations.
Regards
Robert
last question, mqqt message has the same information of json? caouse I wold like to add olso timestamp (but I can do olso from raspberry)
Yes, but you can also customise your own MQTT message to send what you want.
OkOk
I've seen other project for Sky temperature mesurament, with same sensor but they add a germanium lens upper the MLX sensor, what you think about it?
I have not seen that and cannot comment on it without seeing the science behind it.
What I can say is that there are many implementations out there of mySQM+ using the sky modelling [which is why we use the MLX sensor] and it does work very very well without the need for any special lens
ok, is not a lense, but is just a ir pass filter for cover, but it olso need a heater for dew
Hi Stefano
Well I did some research on this and found a bit.
1. real germanium type lenses are very expensive [400+
2. the lenses do cut down the tranmission rate of the ir signal component
3. The lenses may have an uneven response across the IR spectrum
4. there are no real benefits as such because
a. there are no comparative studies down to compare sensors with or without AGAINST a standard measurement - in other words the only tests I could find was against other sensors of the same type or against DHT22 - that in itself is meaningless because DHT22 measures ambient temperature AND is not responsive to IR
b. Some users did use an aluminum sheet angled at 45 degrees so it was measuring reflective IR - again there is a loss involved in efficiency and that loss was never quantified in any meaningful way against a standardised meter for measuring IR, and that loss was never measured across the IR spectrum so there never was a baseline established thus no compensation factor able to be achieved
5. There was some discussion mentioned about FOV and whether the FOW was too large and should somehow be more concentrated. I argue the FOV should be reasonably large - clouds move fast in the sky and before you know it, 5-10min they are overhead - the more warning you get the better, and the modelling being used in mySQM+ is pretty accurate and reliable
In other words, there is a number of questions about the validity. It seems to me that the main reason was exposure of the mlx device to dew/humidity/snow/rain and thus chosing to reflect the IR signals via an angled plate [which then was heated] was their answer. But for me, there are still a lot of unanswered queations as I have pointed out above. I think the jury is still out on this one.
Having said all of that I admire those who tried this and testing their systems etc trying to improve things. We are all trying to do this and make things better for other users out there.
regards
Robert
If one wanted to really to have a relaible and accurate system then I really think it would need to be validated and compared to a real standard instrument capable of measuring IR.