|
Post by doxidad on May 30, 2022 6:57:24 GMT -8
Just ignoring the picture doesn't save power. W Yep you're correct - not sure what I was thinking.
Actually what I was thinking is how not to store images in the database or on disk. Not sure about anybody else, but watching a composite 24 hr video with 8-14hrs of dark is not that exciting.
Looking at the code on the PI, I have a scheme that I'm going to try. If it works I'll publish the code - doesn't look like there is much needed.
|
|
|
Post by Jason on May 31, 2022 3:19:22 GMT -8
I'm not entirely familiar with how SkyCam works, but if you have access to the state with the SkyCam script you should be able to read the current value of state.SunlightVisible (this needs to be confirmed) and throw out the image if it is below a threshold.
Thanks,
Jason
|
|
n7qnm
Junior Member
Posts: 80
|
Post by n7qnm on Jun 1, 2022 15:46:23 GMT -8
I was having power issues as well, so I backed the cycle off to 1800 (1790, actually) seconds. That seems to be working; we've had a couple of partly cloudy days, and the battery voltage is still above 4. At least with the camera, it can be remotely provisioned. The 433 only sensors (AQI, etc) are a real pain there (but that's another thread :-).
I still think the "real" solution is a hardware (photocell) based power cut; but that needs to be small enough to be integrated into the case; or perhaps as an option on the Power board itself. Without an RTC somewhere on the camera side, trying to provision different times when you only get one shot (after the INFO packet) is just asking to miss an entire interval of pictures if that message or the "reprovision" message gets lost somewhere.
If the ESP32 had a "wake on ping", maybe that could be used for "out of band" control messaging.
|
|
|
Post by Jason on Jun 2, 2022 4:44:13 GMT -8
I was having power issues as well, so I backed the cycle off to 1800 (1790, actually) seconds. That seems to be working; we've had a couple of partly cloudy days, and the battery voltage is still above 4. At least with the camera, it can be remotely provisioned. The 433 only sensors (AQI, etc) are a real pain there (but that's another thread :-). I still think the "real" solution is a hardware (photocell) based power cut; but that needs to be small enough to be integrated into the case; or perhaps as an option on the Power board itself. Without an RTC somewhere on the camera side, trying to provision different times when you only get one shot (after the INFO packet) is just asking to miss an entire interval of pictures if that message or the "reprovision" message gets lost somewhere. If the ESP32 had a "wake on ping", maybe that could be used for "out of band" control messaging. Longer term, it would likely be better if the 433 only sensors transitioned to ESP-NOW instead of WiFi. Unfortunately, there is no RPi capability to receive the ESP-NOW protocol. However, an additional ESP32 running on AC can receive the ESP-NOW messages and re-transmit the messages through MQTT. Thanks, Jason
|
|
n7qnm
Junior Member
Posts: 80
|
Post by n7qnm on Jun 2, 2022 10:30:53 GMT -8
OK - you just hit a "hot button" w/me. Why does every vendor have to come up with their own proprietary messaging/communications system? What was SO bad about other ESTABLISHED, STANDARD protocols that they needed their own.
"there is no RPi capability to receive the ESP-NOW protocol" says it all........
And I'm not sure that's relevant for cameras anyway, since the packet size is so limited.
|
|
|
Post by Jason on Jun 2, 2022 10:53:56 GMT -8
My assumption is that ESP-NOW provides advantages over LoRa in some way(s) in addition to alleviating the power demands of WiFi and BT. I agree with you though that new protocols are annoying and I'm curious to see how broadly ESP-NOW gets adopted. I'm still not convinced it is better than LoRa.
Thanks,
Jason
|
|
|
Post by Jason on Jun 2, 2022 11:18:24 GMT -8
|
|