Are you(or have you already) going to expose the the above properties outside of the INO - for those who may not use your excellent board but do want to use your software? The ESP32 allows more precision control of the above on a pin to pin bases and as you already know 16 PWM pins. Have been testing my ESP32/MQTT/Node red for PWM control for a while and it does seem a lot better than the Nano (even the Newer IOT) at PWM signally. The only proble I have found is understanding what is meant by PWM "Channel" - couldn't find a dumb enough explanation(for me) of what use this is other than "grouping". Have you any info on the latter meaning. My version is not Ascom or Indi just MQTT as for me there is no point using either for this in my set up!
Sorted what the "channel" in ESP32 functions is all about - by mistake. it is a grouping mechanism. So for example I have controlled each dew channel by sending values to each but with the "channel" you can assign the same "channel" to each dew channel (even on the fly) which means it simple to get dew channels to follow Dew channel 1 (for example) just by using the same "channel" number.
I have found ,especially for testing ,using "other" boards, its a boon to be able to set the Freq,Resolution and "channel" number outside the Arduino Code (no recompiling) as many PWM boards differ between channels (bad design maybe). So for example the ESP32 PWM outputs seems to be accurate across all pins but many baords produce different outputs. You probably dont have this problem on your disigned board.
At this moment in time I have also tested 0-10v Industry standard "dimmers" (5a per channel o/p) which seems to behave very well. This may give the opputunity for users to use standard oieces of kit - just a thought. The only bug is that I have only found 1 ready made 3.3v to 10V PWM module and that controls only 1 channel.
I am also going to test out DMX versions as this may give another option as they can be networked and again are Industry standardised.
Anyway the above is for info.
Keep up the great work!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These could easily be exposed via JSON, this would both get and set channel and dew output.
I am not sure passing control to an application is desired - it seems to be a waste of host power considering the esp32 can easily do the work - or maybe I misunderstand.
I am not sure reconfiguration is an issue, I would have thought most people would only configure once and then its a matter of set and forget and let the controller do it all automatically?
Would you not require some "intelligence" controlling the dimmer anyhow? In order to be able to control it and alter the output?
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I dont use Json anymore I found out,IMO, its not worth the hassle for very short messages (e.g. :xxxx#).
The ESP32 is doing the all the work but I am able ,via Node Red, to modify ESP32 LEDC function values on the fly remotely (all my kit is remote controlled so no "local" adjustment required via knobs or switches which my version doesn't have). If I need to adjust/see anything when at my Obsys I just use my Phone with Node-red.
I agree that once a board is set up correctly for a particular Dew controller board it would not be used but its great for testing on different boards. It also means the "Dew Channel Following" modes (i.e. Ch2,ch3,Ch4 follow Ch1 settings - or any combo is dead simple - thats what I found out about "ESP32 LEDC Channels" - use the same channel number in the LEDC functions and any values are passed to other GPIO PWM pins that use the same channel numer.
The Dimmer boards tested are really no different to your board just sends 0-10 voltage to alter PWM voltage output. Control is via PWM to control the PWM to voltage module (so 100% cycle gives 10v/5ma to controlling PWM to Voltage module which controls the output to the Dew straps) - just means there are many ready made cheap boards of varioud channel numbers (and current) out there .
Also tested a number of single channel versions of the above which worked well.
As the Node-red flow just uses MQTT and topics its dead simple to control 1 or many channels without changing the Node-red end (currently 1 to 4 channels by defaultand without changes) too much.
As I had already been successfully using WEMOS D1 Mini/Node-Red/MQTT on my first version of mechanical Dew Strap controller I just used the same techniques but changed to digtal PWM control for this version.
The biggest difference is that my temp/humidity sensors are autonomous from the ESP32 - mainly because they already existing in my first version and didn't need changing as they report values via MQTT anyway.
Robert are you using any form of feedback from the output side of you board or just relying on the Temp sensors to indicate that all is well ?
P.S. I have even have added MQTT bridging(via older RPI3's as backup/loaded bearing - but doubt I will need it.
I am just sharing my different approach ,bouncing my ideas and getting your useful valued electronics tech feed back as always :-)
Regards
Clive
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Clive
I am getting too old now to follow half of what you said.
I am using MQTT to monitor the ESP32 version. Currently I see little need to make any adjustments via commands from any app. The goal is to have the device "manage" and for me to "forget" to control it.
I had tossed up whether to use my other project "Daughter board ESP32" I developed. This is an ESP32 which supports web-server, MQTT, JSON and ESPNOW for data transfer and device control.
The board provides multiple digital IO pins, mulriple relay outputs and multiple I2C interfaces.
In essence I developed it as a way of implementing remote devices that could be inter-connected.
The project mySQM+ was a means to test this out, so rather than redesign the main controller it was a matter of adding a sub-board with sensors instead, and provide a safe and reliable transport mechanism for exchange of data and control. There are many examples using the daughter board with remote sensors such as BME280, UV, IR, Lightning etc. I attach info. The daughter board was designed for low cost, and ease of use.
I do think there is room for having a more distributed architechure with interlinked nodes. In that sense each node could provide input to say "a dew controller" and "a weather station" at the same time. Of course a node going off-line in such a distributed architecture would affect all upstream connected controllers.
"Getting too old" - rubbish you are never too old and you show that with your numerous projects and workload !
I hadn't seen your mySQM+ project before looks interesting but too complicated for me - I was taught KISS from the start of my IT days - you couldn't get complicated with breadbaords.:-) But good to know people are searching out new ideas!
I will stick with me MQTT approach,for now, as it has served me well enough - for my needs anyway. I am just waiting for my RPI Compute 4 module (may 2021 - what!) so that I can replace my older RPI3's as the MQTT brokers unless a newer ESP or the like appears which can run a reliable well support MQTT broker - the ones I have looked at on ESP32 (and previous) were not suitable at all. If the Compute 4 Modules work as expected I am also updating my Indi set up to use RPI CM4 with command line Indiserver at each device - mount,camera's (exclude "small low usage devices" such as Focusers ,f/wheels etc). I already use CCDCIEL this way. Just wish Indi would have generic drivers which one could use - IMHO there are too many drivers to support!
I appreciate your Dew Controller is "fit and forget" which is great but I like things a bit more controlled - just different thats all. Lets hope nobody tries to sell your project as with that other "gentleman". It still annoys me that some in the Astro world dont care as long as it makes it cheap for them.
Anyways - Its not really a suggestion but I am looking for a method to read the PWM signals (but doesn't have to be) received at the Dew Heaters so I can represent a real "whats actually going on at the coal face" on my monitoring system. If that makes sense - hence the question about "feed back".
Kind Regards
Clive
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Clive
I updated the PDF now - intent is towards the direction you have suggested. I have started with JSON interface to be able to get or set values in the controller. Means you can even do that using Python on Pi. I have also used Curl to control channels etc. I am using a Get/Set format with parameters
As the firmware already supports MQTT, it would not be too hard to also hadd those extensions into MQTT. So one could send data and receive commands over MQTT using a similar protocol extension as used about (Get and Set).
Next step is to develop client side html pages with scripts to do same thing - very similar to Node-Red - basics are working now with examples but given time I will do more on this.
Small steps at a time - I have my idle brain working on another issue - I forked off a brain task to work out how to expand the controller mode to a "remote control" type as well as "normal": - in "remote control" then you can control using json, curl, python etc and the controller would do as it was told - and the "normal mode" meaning the way it operates now.
The hope being a way of allowing a greater degree of client control where users can write their own clients- my forked brain task will no doubt signal me with a eureka update when that task completes.
Best regards for a new year
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have updated my test rig and now I can read the output of the PWM voltage as being used by Dew Straps. Not entirely accurate but at least I can tell something is working when remote. Guess I need to monitor Power(current) to know that dew strap is realing working - but thats another matter. Updated my Node Red to allow control of ESP32 LEDC set up value remotely - still testing but works.
You will be using REST next - if you dont already LOL :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not got that far yet I want to get my test rig converted into something to replace my existing dew system. Then I will look to "upgrades". As last years skies were rubbish I guess the upgrades will come sonner if 2021 continues where 2020 left off :-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Robert I will read and see if it meets my needs.
At the moment I am just fine tuning the voltage monitor which works well except for the fact the signals are not linear,so top and bottom see little difference in values. But it works and is shown up on my Node-red. Fun - Thanks for the info. Stay dafe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quite please it works (subject to bad temp connectors and fault channel 1 on board). Had to reread esp32 pin usage on ttgoesp32 board as 2 of pins were shared with booting which caused problems with new INO upload. Just need to get another board and hope its not a manu problem. Quite chuffed for someone who knows zero about electronics LOL. How is your ESP32 project going any problems,oddities?
Hi Clive
I think I need some instruction on you re node-red and how you did that fancy page. My skills in Node-red are minimal.
The myDCP4ESP32 work is nearing release time. I am just cleaning up the documentation and firmare for uploading, so it will not long now.
It will probably be in an advanced state when released compared to the many other projects which were developed over time (in some cases years) gradually getting better.
This one I basically threw the kitchen sink at it from day 1 and put everything I could think of into the design/coding, even if those features are never used. I included JSON and HTML support for getting and setting just about everything, as well MQTT get/set functionality.
Cheers
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fancy Node-red page - your kidding LOL. Glad to give what ever little knowledge/help I have on Node-red.
I have just decided to change my set up at the Ardiono end - instead of one complete set up I have broken down the channels into self contained channels - so 1 ESP per channel and 1 ESP per voltage monitor. A little over indulgent maybe but does make a lot of difference to my Web end (i.e. Node-red) as it just see's MQTT topic coming in - idea is to be more modular. Just looking for very small ESP32's (e.g. Tiny esp32 looks ok but costly) with enough PWM/ADC pins ( only need a couple per board).
Just wish I had you electronics knowledge as I have to dig for stuff then read if its suitable - 1/2 the fun I guess.
I have added a "trimming PWM " page to adjust PWM values and I have made these "persistant" global parameters within Node-red . Attached pic shows remap to "fine tune" PWM - these are saved between sessions as "Persistant" global parameters. Decide to limit PWM to 20,40,60,80 and 100% - so in my case that provides 2.5,4,5,8 ,11 and 12V when read with a std voltmeter.
You must have spent many hours to get the first version of your ESP32 Dew controller working - hope people appreciate it. Like you say projects evolving over years is one thing coming out 100% designed/working means a lot of work - Well done,give yourself a pat on the back !
Stay Safe and Clear skies (no idea what the latter are LOL)
P.S. When are you starting on a Rotator for a camera - Looked into building one . Software side simple (filter wheel) but lightweight /secure/wobble free hardware seems to be the hard bit. Next project LOL
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FYI - I dont know if you have used one and it probably hasn't enough pins for your project BUT I can confirm that the ESP32 Mini (sometimes refered too as Wemos esp32 Mini) works just as well as TTGO,Lolin esp32 and Greekit esp32. As I am a bad soldier and the twin pins I found a bit of a fiddle. Added Ds18B20 temp probe for Dew band temp monitor - Nodered now looks like attached picture - the green led being a "comfort" indicator as I use separate Volts/Dew Band Temp Probe!
HI Robert,
Have Xmas and New year.
Are you(or have you already) going to expose the the above properties outside of the INO - for those who may not use your excellent board but do want to use your software? The ESP32 allows more precision control of the above on a pin to pin bases and as you already know 16 PWM pins. Have been testing my ESP32/MQTT/Node red for PWM control for a while and it does seem a lot better than the Nano (even the Newer IOT) at PWM signally. The only proble I have found is understanding what is meant by PWM "Channel" - couldn't find a dumb enough explanation(for me) of what use this is other than "grouping". Have you any info on the latter meaning. My version is not Ascom or Indi just MQTT as for me there is no point using either for this in my set up!
Hi Clive
Not sure what you mean by exposing the properties outside on ino?
Cheers
Robert
Oh
ESP32 Freq,Duty cycle and Resolution
500, 0-100&, 8
Hi Robert ,
Sorted what the "channel" in ESP32 functions is all about - by mistake. it is a grouping mechanism. So for example I have controlled each dew channel by sending values to each but with the "channel" you can assign the same "channel" to each dew channel (even on the fly) which means it simple to get dew channels to follow Dew channel 1 (for example) just by using the same "channel" number.
I have found ,especially for testing ,using "other" boards, its a boon to be able to set the Freq,Resolution and "channel" number outside the Arduino Code (no recompiling) as many PWM boards differ between channels (bad design maybe). So for example the ESP32 PWM outputs seems to be accurate across all pins but many baords produce different outputs. You probably dont have this problem on your disigned board.
At this moment in time I have also tested 0-10v Industry standard "dimmers" (5a per channel o/p) which seems to behave very well. This may give the opputunity for users to use standard oieces of kit - just a thought. The only bug is that I have only found 1 ready made 3.3v to 10V PWM module and that controls only 1 channel.
I am also going to test out DMX versions as this may give another option as they can be networked and again are Industry standardised.
Anyway the above is for info.
Keep up the great work!
Hi Clive
These could easily be exposed via JSON, this would both get and set channel and dew output.
I am not sure passing control to an application is desired - it seems to be a waste of host power considering the esp32 can easily do the work - or maybe I misunderstand.
I am not sure reconfiguration is an issue, I would have thought most people would only configure once and then its a matter of set and forget and let the controller do it all automatically?
Would you not require some "intelligence" controlling the dimmer anyhow? In order to be able to control it and alter the output?
Robert
Hi Robert,
I dont use Json anymore I found out,IMO, its not worth the hassle for very short messages (e.g. :xxxx#).
The ESP32 is doing the all the work but I am able ,via Node Red, to modify ESP32 LEDC function values on the fly remotely (all my kit is remote controlled so no "local" adjustment required via knobs or switches which my version doesn't have). If I need to adjust/see anything when at my Obsys I just use my Phone with Node-red.
I agree that once a board is set up correctly for a particular Dew controller board it would not be used but its great for testing on different boards. It also means the "Dew Channel Following" modes (i.e. Ch2,ch3,Ch4 follow Ch1 settings - or any combo is dead simple - thats what I found out about "ESP32 LEDC Channels" - use the same channel number in the LEDC functions and any values are passed to other GPIO PWM pins that use the same channel numer.
The Dimmer boards tested are really no different to your board just sends 0-10 voltage to alter PWM voltage output. Control is via PWM to control the PWM to voltage module (so 100% cycle gives 10v/5ma to controlling PWM to Voltage module which controls the output to the Dew straps) - just means there are many ready made cheap boards of varioud channel numbers (and current) out there .
This is the ready made PWM to Voltage(0-10v) I used http://www.icstation.com/voltage-converter-module-adjustable-converter-power-module-digital-analog-signal-p-12498.html
This is one of the ready made 0-10v 5A 3 channel "boards" i tested https://www.vieep.com/index.php/12-24v-3ch-cv-0-10v-dimmer-dim116-euchips-dimming-led-controller.html
And this is one of more direct PWM boards tested with ESP32 / ESP8256 and Nano IOT 33 https://www.ebay.co.uk/itm/Signal-Trigger-Switch-Module-MOS-FET-F5305S-Direct-Current-Control-fr-PWM-Motor/323872130674?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
Also tested a number of single channel versions of the above which worked well.
As the Node-red flow just uses MQTT and topics its dead simple to control 1 or many channels without changing the Node-red end (currently 1 to 4 channels by defaultand without changes) too much.
As I had already been successfully using WEMOS D1 Mini/Node-Red/MQTT on my first version of mechanical Dew Strap controller I just used the same techniques but changed to digtal PWM control for this version.
The biggest difference is that my temp/humidity sensors are autonomous from the ESP32 - mainly because they already existing in my first version and didn't need changing as they report values via MQTT anyway.
Robert are you using any form of feedback from the output side of you board or just relying on the Temp sensors to indicate that all is well ?
P.S. I have even have added MQTT bridging(via older RPI3's as backup/loaded bearing - but doubt I will need it.
I am just sharing my different approach ,bouncing my ideas and getting your useful valued electronics tech feed back as always :-)
Regards
Clive
Hi Clive
I am getting too old now to follow half of what you said.
I am using MQTT to monitor the ESP32 version. Currently I see little need to make any adjustments via commands from any app. The goal is to have the device "manage" and for me to "forget" to control it.
I had tossed up whether to use my other project "Daughter board ESP32" I developed. This is an ESP32 which supports web-server, MQTT, JSON and ESPNOW for data transfer and device control.
The board provides multiple digital IO pins, mulriple relay outputs and multiple I2C interfaces.
In essence I developed it as a way of implementing remote devices that could be inter-connected.
The project mySQM+ was a means to test this out, so rather than redesign the main controller it was a matter of adding a sub-board with sensors instead, and provide a safe and reliable transport mechanism for exchange of data and control. There are many examples using the daughter board with remote sensors such as BME280, UV, IR, Lightning etc. I attach info. The daughter board was designed for low cost, and ease of use.
I do think there is room for having a more distributed architechure with interlinked nodes. In that sense each node could provide input to say "a dew controller" and "a weather station" at the same time. Of course a node going off-line in such a distributed architecture would affect all upstream connected controllers.
What suggestions do you have in mind?
Cheers
Robert
Hi Robert ,
Happy New year - in advance just.
"Getting too old" - rubbish you are never too old and you show that with your numerous projects and workload !
I hadn't seen your mySQM+ project before looks interesting but too complicated for me - I was taught KISS from the start of my IT days - you couldn't get complicated with breadbaords.:-) But good to know people are searching out new ideas!
I will stick with me MQTT approach,for now, as it has served me well enough - for my needs anyway. I am just waiting for my RPI Compute 4 module (may 2021 - what!) so that I can replace my older RPI3's as the MQTT brokers unless a newer ESP or the like appears which can run a reliable well support MQTT broker - the ones I have looked at on ESP32 (and previous) were not suitable at all. If the Compute 4 Modules work as expected I am also updating my Indi set up to use RPI CM4 with command line Indiserver at each device - mount,camera's (exclude "small low usage devices" such as Focusers ,f/wheels etc). I already use CCDCIEL this way. Just wish Indi would have generic drivers which one could use - IMHO there are too many drivers to support!
I appreciate your Dew Controller is "fit and forget" which is great but I like things a bit more controlled - just different thats all. Lets hope nobody tries to sell your project as with that other "gentleman". It still annoys me that some in the Astro world dont care as long as it makes it cheap for them.
Anyways - Its not really a suggestion but I am looking for a method to read the PWM signals (but doesn't have to be) received at the Dew Heaters so I can represent a real "whats actually going on at the coal face" on my monitoring system. If that makes sense - hence the question about "feed back".
Kind Regards
Clive
Hi Clive
Best wishes your way too.
I had investigated PID control of the dew straps similar to that used in 3d printers to control the heat bed and nozzle.
After a lot of experimenting I came to the conclusion that is was a lot of extra work for small rewards.
Regards
Robert
OK thanks I will investigate PID
Clive
I updated the PDF now - intent is towards the direction you have suggested. I have started with JSON interface to be able to get or set values in the controller. Means you can even do that using Python on Pi. I have also used Curl to control channels etc. I am using a Get/Set format with parameters
As the firmware already supports MQTT, it would not be too hard to also hadd those extensions into MQTT. So one could send data and receive commands over MQTT using a similar protocol extension as used about (Get and Set).
Next step is to develop client side html pages with scripts to do same thing - very similar to Node-Red - basics are working now with examples but given time I will do more on this.
Small steps at a time - I have my idle brain working on another issue - I forked off a brain task to work out how to expand the controller mode to a "remote control" type as well as "normal": - in "remote control" then you can control using json, curl, python etc and the controller would do as it was told - and the "normal mode" meaning the way it operates now.
The hope being a way of allowing a greater degree of client control where users can write their own clients- my forked brain task will no doubt signal me with a eureka update when that task completes.
Best regards for a new year
Robert
Well Done !
I have updated my test rig and now I can read the output of the PWM voltage as being used by Dew Straps. Not entirely accurate but at least I can tell something is working when remote. Guess I need to monitor Power(current) to know that dew strap is realing working - but thats another matter. Updated my Node Red to allow control of ESP32 LEDC set up value remotely - still testing but works.
You will be using REST next - if you dont already LOL :-)
Something like the ACS712 Current Sensor Module would work?
Not got that far yet I want to get my test rig converted into something to replace my existing dew system. Then I will look to "upgrades". As last years skies were rubbish I guess the upgrades will come sonner if 2021 continues where 2020 left off :-(
Clive
This was the link re the PID stuff, with examples
https://github.com/r-downing/AutoPID
Thanks Robert I will read and see if it meets my needs.
At the moment I am just fine tuning the voltage monitor which works well except for the fact the signals are not linear,so top and bottom see little difference in values. But it works and is shown up on my Node-red. Fun - Thanks for the info. Stay dafe.
Quite please it works (subject to bad temp connectors and fault channel 1 on board). Had to reread esp32 pin usage on ttgoesp32 board as 2 of pins were shared with booting which caused problems with new INO upload. Just need to get another board and hope its not a manu problem. Quite chuffed for someone who knows zero about electronics LOL. How is your ESP32 project going any problems,oddities?
Last edit: clive stachon 2021-01-17
Hi Clive
I think I need some instruction on you re node-red and how you did that fancy page. My skills in Node-red are minimal.
The myDCP4ESP32 work is nearing release time. I am just cleaning up the documentation and firmare for uploading, so it will not long now.
It will probably be in an advanced state when released compared to the many other projects which were developed over time (in some cases years) gradually getting better.
This one I basically threw the kitchen sink at it from day 1 and put everything I could think of into the design/coding, even if those features are never used. I included JSON and HTML support for getting and setting just about everything, as well MQTT get/set functionality.
Cheers
Robert
Hi Robert,
Fancy Node-red page - your kidding LOL. Glad to give what ever little knowledge/help I have on Node-red.
I have just decided to change my set up at the Ardiono end - instead of one complete set up I have broken down the channels into self contained channels - so 1 ESP per channel and 1 ESP per voltage monitor. A little over indulgent maybe but does make a lot of difference to my Web end (i.e. Node-red) as it just see's MQTT topic coming in - idea is to be more modular. Just looking for very small ESP32's (e.g. Tiny esp32 looks ok but costly) with enough PWM/ADC pins ( only need a couple per board).
Just wish I had you electronics knowledge as I have to dig for stuff then read if its suitable - 1/2 the fun I guess.
I have added a "trimming PWM " page to adjust PWM values and I have made these "persistant" global parameters within Node-red . Attached pic shows remap to "fine tune" PWM - these are saved between sessions as "Persistant" global parameters. Decide to limit PWM to 20,40,60,80 and 100% - so in my case that provides 2.5,4,5,8 ,11 and 12V when read with a std voltmeter.
You must have spent many hours to get the first version of your ESP32 Dew controller working - hope people appreciate it. Like you say projects evolving over years is one thing coming out 100% designed/working means a lot of work - Well done,give yourself a pat on the back !
Stay Safe and Clear skies (no idea what the latter are LOL)
Clive
It looks like one of those monitor things that Doc Bones had in the sick bay of "Star-Trek"
LOL yep
P.S. When are you starting on a Rotator for a camera - Looked into building one . Software side simple (filter wheel) but lightweight /secure/wobble free hardware seems to be the hard bit. Next project LOL
I had started rotator at
https://sourceforge.net/projects/arduino-myrotator/
but have done zero work on this for zome time
I would also refer you to these
http://www.scopefocus.info/home/rotator
and
https://www.cloudynights.com/topic/642680-3d-printed-de-rotator-for-moonlite-25-focuser-and-gso-coma-corrector/
thanks Robert for the info
FYI - I dont know if you have used one and it probably hasn't enough pins for your project BUT I can confirm that the ESP32 Mini (sometimes refered too as Wemos esp32 Mini) works just as well as TTGO,Lolin esp32 and Greekit esp32. As I am a bad soldier and the twin pins I found a bit of a fiddle. Added Ds18B20 temp probe for Dew band temp monitor - Nodered now looks like attached picture - the green led being a "comfort" indicator as I use separate Volts/Dew Band Temp Probe!