[-] Starfighter@discuss.tchncs.de 3 points 1 week ago

Why not set up backups for the Proxmox VM and be done with it?

Also makes it easy to add offsite backups via the Proxmox Backup Server in the future.

[-] Starfighter@discuss.tchncs.de 9 points 1 month ago

This person had the same issue and they've just logged out and in again

[-] Starfighter@discuss.tchncs.de 20 points 2 months ago

Always mocking Dr. Daniel Jackson. Poor guy

[-] Starfighter@discuss.tchncs.de 5 points 2 months ago

Additional information regarding Home Assistant:

The sun component (which should be enabled by default) already computes the sun position for you.

Elevation and azimuth are available as standalone sensors sensor.sun_solar_azimuth (might be disabled by default) or as attributes on the sun.sun entity.

[-] Starfighter@discuss.tchncs.de 1 points 3 months ago

I don't have any experience with it but this might do something along those lines(?):

https://esphome.io/components/binary_sensor/ble_presence.html

Seems like you can just add it to one or more of your existing esphome devices.

[-] Starfighter@discuss.tchncs.de 18 points 7 months ago* (last edited 7 months ago)

Out of curiosity I've let it rate Low<-Tech Magazine, a website run on an ARM SBC powered exclusively with off-grid solar power, and that only achieves 87% / A.

Link to results

[-] Starfighter@discuss.tchncs.de 1 points 7 months ago

Can't exactly remember which car it was but some of the early and smaller EVs didn't necessarily come with a navigation system. Think along the lines of Chevy Bolt or Nissan Leaf.

[-] Starfighter@discuss.tchncs.de 1 points 7 months ago* (last edited 7 months ago)

Not OSM or Open Source but "A Better Route Planner" (ABRP) was one of the first good EV routing apps and got pretty popular.

Especially early on it was often smarter than the built-in routing systems if the car even had one.

Also available as a website: ABRP

[-] Starfighter@discuss.tchncs.de 3 points 7 months ago

If you have such a system up and running already you could try to modify it before ripping it out and starting from scratch.

Borrowing an idea from the machine learning approach you could additionally take the difference in average outside temperature yesterday and the average forecasted outside temperature today. Then multiply that by a weight (the machine learning approach would find this value for you but a single weight can also be found by hand) and subtract it from the target temperature before the division step discussed previously. Effectively saying "you don't need to heat as much today since it will be a little warmer".

I fear that's about all you can do with this approach without massively overcomplicating things.

[-] Starfighter@discuss.tchncs.de 14 points 7 months ago* (last edited 7 months ago)

This is effectively what a thermostat does.

The problem is that the controller won't know how well insulated each room is, how cold it is outside (including wind speed), which doors and windows are open and when, what people or devices are doing in each room.

The way thermostats solve this is by creating a closed loop where they react to how the room reacts to their actions.

Depending on how your heaters work you'll likely need some dynamic component to react to these unforeseen changes unless you can live with the temperature being very unstable.

To get a rough idea of how long the heaters will have to run you can look at each room in for the last n days and see if the heater's runtime was long enough to (on average) hold your target temperature. Dividing the average temperature with the target temperature will give you an idea whether they were on for too long or too short. (If the heaters have thermostats you'll likely need to subtract a small amount from that value so that it will settle at the minimum required heating time)

If that value is close to 1.0 you know that on those days the heating time was just about perfect.

Once that is the case you can take the previous days heating time and divide it up over the cheapest hours. The smaller of a value n you choose the more reactive the system will be but it will also get a little more unstable. Depending on your house and climate this system described here might simply be unsuitable for you because it takes too long to react to changes.

There are many other ways to approach this very interesting problem. You could for example try to create a more accurate model incorporating weather and other data with machine learning. That way it could even do rudimentary forecasting.

[-] Starfighter@discuss.tchncs.de 11 points 8 months ago

Are there any implementations of this out there or is this purely theoretical (at this point in time)?

21
submitted 1 year ago* (last edited 1 year ago) by Starfighter@discuss.tchncs.de to c/askelectronics@discuss.tchncs.de

Hi, this post is structured similarly to r/PrintedCircuitBoard 's review request format. Since we don't have any PCB communities over here yet, I thought that this might fit in here and can maybe spark some friendly discussion.

This is a relay board controlling electrically driven windows and blinds. For this purpose it has some additional connectors to a weather station, interior sensors and an LCD screen.

It is replacing a ~20 year old board that has started to develop some annoying quirks. I've mostly copied what the original board did and adjusted it for the ESP32. This is not a production board and if all goes well, I will only ever assemble a single one of these.

The primary usage scenario is that the MCU will monitor the weather station and then actuate the motor groups (M1 - M6 connected on J3 - J8) to keep the indoors temperature and humidity in check.

At least during summer time the board will likely run 24/7 and will hopefully be used for a number of years. For maintenance reasons I've tried to keep it simple and the component count low.

Mains power is supplied from J1 and being fed to the motors via the relays. PS1 converts the line voltage to +5V DC for the relay coils and some auxiliary components. The switching regulator U2 steps that down to +3.3V for the MCU U1 and IO Expander U3.

The board size is mostly constrained by the preexisting mounting holes which gives me plenty of space to work with even with just a 2 layer board. The enclosure containing the mounts is installed indoors and is finger-pokey-tight.

Jumper JP1 allows me to supply the MCU devkit daughter board with +5V, should I ever replace it with a different one. Similarly J11 exists for future expansion.

J10 mounts another daughter board (not included in review) facilitating communications with the weather station. Should the station ever need to be replaced I can swap in a new, matching board.

There aren't any high-speed connections on the board. The fastest one is likely the SPI connection to the LCD controller but I can slow it down in firmware if necessary.

Regarding the DNP components: There are only 5 motors installed at the moment so I will cover the sixth slot with a piece of plastic for now. R1 and R2 will only be populated if the 10k pullup resistors integrated into the MCU are insufficient for typical baud rates.

While it is not the first board I've designed, it is the first one carrying mains power (European grid 230V@50Hz). I'm using 2 oz copper to accommodate the motor currents within reasonably wide traces.

In case anyone is interested, it will be running the ESPHome firmware to easily integrate with the Home-Assistant smart home solution. This also pushes firmware maintenance from me onto the ESPHome devs.

3D render from front (no 3D model for relays K** and MCU board; 3D model for J1 and J2 is a stand-in of same outer dimensions): 3D Front

Orthographic view from front: Orthographic Front

Schematic:

Schematic

PCB All layers (For reference: thickest traces are 2.5 mm / ~98.4 mils; thinnest traces are 0.25 mm / ~9.84 mils): All layers

PCB Front layers excluding Silkscreen: Front layers

PCB Back layers + Front Fab layer: Back layers

view more: next ›

Starfighter

joined 1 year ago