As the OP mentioned, seems inefficient to upload RAWs for processing and culling online. However, extracting and uploading the embedded or sidecar full-res JPEG, editing that non-destructively, then applying the edits to the offline RAW copy seems like it might work better.
USD is backed by the U.S. military force, via a slippery slope: you can only pay taxes in USD, and if the taxes you owe are large enough and you refuse to pay, the U.S. government will send increasingly larger forces to claim those taxes.
As long as the docker daemon starts on startup, there's a `restart: always` option in the docker-compose.yml config file that takes care of it. Using `depends_on: [list]` takes care of startup order cleanly.
I agree with you. Removing anything off-chain from the conversation, we're left with the equivalent of selling a million pixels on a web page (but at least there was some utility to that, in the form of advertising).
I'd argue that this limitation is artificial as well. With some painting forgeries, you're getting down to the molecular or brushstroke level of differentiation. It's all about the value that we humans assign to what's considered "an original", and I think that's what's happening with NFTs today. Unlike tangible art, however, I think NFT art is much more volatile and prone to the Beanie Babies effect if its popularity wanes.
In that scenario, trust shifts to somewhere the U.S. cannot easily regulate. In case of crypto, that can just be banned and rendered useless, as long as the rest of the world is USD-bound.
If a crypocurrency becomes popular in another country using another currency to on- and off-board, see my comment.
It would take a miracle for cryptocurrencies to suddenly replace fiat without being bound to any fiat currency. Essentially, all the world would need to switch trust at once.
The (U.S.) dollar is backed by the U.S. Army and always will be. Confidence decreases? The U.S. will likely start a war with the country whose currency tries to replace it (on "national security" reasons).
I Ctrl-F'ed for Twist, made by the team at Todoist, but couldn't find it.
It has a way to go, but I found it the right mix of persistent, long-form discussion and decision making using Threads, and sync communication using Messages. It's the best of both worlds, if you can educate a team to use it properly.
You might be thinking of utility classes as the finished product. They're incredibly useful for quickly prototyping and "jiggling" things until they look good.
Once that's done, the utility classes can be extracted to reusable CSS via the `@apply` directive.
A Hall sensor on each window (aka open/close sensor), plus temperature sensors in each room and one placed outside.
When the window is closed, but the outside temperature is lower that inside, it sends a notification to open the window. The opposite happens when the outside temperature exceeds the one inside, unless the window is already closed.
This is all written in Python via appdaemon since it's easier than defining the same automation via the UI (although that's also doable nowadays).
I use Aeotec Z-Wave Multisensors permanently connected to USB power (they can also run on battery). However, any PIR motion sensor would work, such as the cheap models from Xiaomi (but there's the extra cost of battery changes).
I use a Z-Wave 6-in-1 multisensor from Aeotec in each room, strategically placed in the corners so as to cover only motion in a single room. That takes care of motion sensing, temperature, humidity and luminosity (not used for automation, purely informative). The other two are UV and vibration sensors that are not as useful.
Setting a short motion detector rearm time lets me start a decay timer for the light that just turned on. If no motion is detected again, it starts lowering the intensity gradually over 10 minutes and finally turning the light off. I added a button in HA to override this and keep the light on when needed.
kevinsundar below is entirely correct, that's how I have mine set up as well. However, instead of network detection, there are multiple GPS-based device tracker methods for proximity.
AppDaemon would be great for that, as the callback methods it requires for listening to state changes or scheduled timer can be independently unit tested and debugged.