The original code was not updating loopTime in the if() block, so it would never be true? @laf0138 give @ScruffR’s code a test and let us know how it’s working. Thanks for taking the time to do the re-write @ScruffR ! 
3 Likes
Thanks for the re-write !!! Couple quick questions on your coding.
On D5 GND: It’s a GND because you placed the pin in LOW with digitalWrite(DHTGND, LOW); ??
On A3 the INPUT for sensing the Projector trigger. The projector trigger is 12Vdc, I was planning on using Voltage Divider with R1 & two R2’s to knock the Vdc down to 1Vdc. Is this overkill? Or a good idea? (see below). Last one, why wouldn’t A3(DAC) be PinMode (DAC, INPUT); if your reading the 12Vdc trigger from the projector? Then down in the void loop () “if” you do an analogRead (projector); on something you defined as an OUTPUT?
THANKS AGAIN !!
LaneF
Voltage Divider LINK
@BDub Thank you for your input!
Not sure what’s going on with all of the outputs and inputs and what they hook to… but as for the 12V sensing… be very careful not to lose a ground connection on the resistor that connects to your analog input. If you do, it will apply all 12V to that input which will destroy it. A good idea would be to ensure you add a 3.3V zener diode in parallel with the analog/gnd input. Now you’ve protected your input and at the same time provided two paths that would need to be removed before potential damage to the input could occur. If you make sure to not use cheap jumpers than can fall apart, all the better.
1 Like
Exactly!
analogRead() uses a very special mode of the pin which is neither INPUT nor OUTPUT, so not setting it to INPUT does not automatically make it an OUTPUT either, it just lets it be as is (which is after starup high-z).
But if you do set pinMode() on a pin that you will later use as an analogRead() pin the analogRead() instruction will remeber the original pinMode() switch into AN_INPUT mode and after that switch back - which you don't need, so just don't set the mode and save the time of setting and resetting.
Update:
The docs state this too
And about the voltage divider Brett has already given you the best of advices 
@ScruffR great information, thanks for clearing that up.
@BDub Brett, that diode is a perfect fit. Guaranteed protection. I’ll do both as you suggested.
Thanks
LaneF
2 Likes
In a PM session we established that a contributing factor in the elongated debugging process might have been Blynk.
When running a sketch with Blynk then OTA flashing does tend to get interrupted causing the new code not to stick and you’re left with your own not working code and you will just bang you head since nothing you try works.
After flashing in Safe Mode the reworked code stuck and now things look brighter again.
As a rule of thumb. When debugging, always add some means of knowing if you’ve actually the code running you think you have (e.g. D7 blinks, serial prints, version numbers, …).
2 Likes
Interesting @ScruffR about the interrupted OTA updates. Was multi-threading involved, or just the code above?
Also, here’s another way to know when new firmware is running on your device. Watch the event stream and check for a new spark/device/app-hash event: https://docs.particle.io/reference/api/#app-hash which signifies new firmware is running on the device.
1 Like
@BDub, no there was no MT going on.
The sketch I provided above did show exactly the same behaviour on my two test Photons (one 0.4.9, one 0.5.0-rc.1) and there never was an app-hash event, but the expected magenta with some unexpectedly long dark phase and no disconnect/reconnect USB notification sound.
Also some obscure indicators of OTA failure.
Not sure if you have this setup still, but if so would you please test the effect of commenting out temp();? I’m thinking the interrupt driven DHT library will cause an issue with OTA updates in single-threaded mode. If the OTA update begin event could be used to do something to cancel all pending temperature requests… that would be useful. Just a volatile flag to disable the DHT.isrCallback(); call might do the trick. If that’s not super clear, just say so and I’ll give you some more details 
1 Like
@BDub, (un)commenting the temp; call does make no difference whatsoever.
But as I already said Blynk does.
However I found out a bit more.
It’s not the Blynk calls as such but if you have the Blynk app running on your phone while attempting an OTA.
I kind of looked through the Blynk source code to see if I could find any interrupts or things that could happen asynchronously that would interrupt the OTA update… and didn’t see any. So at the moment I’m a bit at a loss to why that would cause the issue.
Could it be that the app is hitting the REST API a bit overenthusiastic - not neccessarily via interrupts.
The Blynk app? That uses their own server and talks directly to the associated TCP socket open. I doubt there is that much data coming from the server unsolicited, and also unclear what will happen in the case that it does when loop() ends and the OTA update begins. I’m also not sure if the TCP client is always active for the Blynk library or if it is created and destroyed during each use. In either case, perhaps the OTA update begin event can be used to toggle a halt on the Blynk network connection. Is there a Blynk.end() command?
@ScruffR
What is this section of code supposed to do?
fanStatus += 10;
fanStatus %= 4096;
I know that 4096 refers to the resolution of the pin DAC but the symbols and the 10 have me puzzled.
Thanks LaneF
It increases fanStatus by 10 each time (the same as fanStatus = fanStatus + 10;).
And the next limits the value to 4095 (the same as fanStatus = fanStatus % 4096;).
% Modulus Operator calculates the remainder of after an integer division.
11 % 5 = 1 <-> 11 / 5 = 2 -> 2 * 5 = 10 -> 11 - 10 = 1
O’ - thank you for the explanation.
LaneF