Add network documentation

.gitea/workflows/release.yaml

@@ -8,11 +8,6 @@ on:
 jobs:
   build:
     runs-on: ubuntu-22.04
-    container:
-      image: git.nicelycomposed.codes/koshyk-io/flutter-gitea-action-image-builder:latest
-      credentials:
-        username: ${{ secrets.IMAGE_REGISTRY_USER }}
-        password: ${{ secrets.IMAGE_REGISTRY_PASSWORD }}
     steps:
       - name: Checkout source code
         uses: actions/checkout@v4
@@ -29,19 +24,19 @@ jobs:
         working-directory: ${{ gitea.workspace }}
         run: |
           yarn build
-      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
       - name: Login to Registry
         uses: docker/login-action@v3
         with:
           registry: git.nicelycomposed.codes
           username: ${{ secrets.IMAGE_REGISTRY_USER }}
           password: ${{ secrets.IMAGE_REGISTRY_PASSWORD }}
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
       - name: Build docker image
         uses: docker/build-push-action@v6
         with:
           context: .
           push: true
           tags: |
-            git.nicelycomposed.codes/yehor/www-yevi-org:${{ gitea.ref_name }}
-            git.nicelycomposed.codes/yehor/www-yevi-org:latest
+            git.nicelycomposed.codes/yevi.org/www-yevi-org:${{ gitea.ref_name }}
+            git.nicelycomposed.codes/yevi.org/www-yevi-org:latest

README.md

@@ -24,18 +24,3 @@ $ yarn build
 
 This command generates static content into the `build` directory and can be served using any static contents hosting service.
 
-### Deployment
-
-Using SSH:
-
-```
-$ USE_SSH=true yarn deploy
-```
-
-Not using SSH:
-
-```
-$ GIT_USER=<Your GitHub username> yarn deploy
-```
-
-If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

blog/2018-06-21-making-a-wifi-enabled-smart-air-humidifier/index.md

@@ -2,6 +2,7 @@
 slug: making-a-wifi-enabled-smart-air-humidifier
 title: "DIY Smart Appliance: Making a WiFi-enabled smart air humidifier from a regular one"
 tags: [smart home, DIY, ESP8266, ESPHome, humidifier, Wemos D1 mini, WiFi]
+image: /img/blog/2018/06/001.jpg
 ---
 
 So there was a simple air humidifier… Actually, this post is a good example of how to make your regular boring home appliance a little smarter. The main part of my humidifier will be the Wemos (or Lolin) D1 mini board based on the ESP8266 WiFi chip.

blog/2019-02-15-smart-doorbell-with-xiaomi-aqara-button-and-google-home/index.md

@@ -0,0 +1,52 @@
+---
+slug: smart-doorbell-with-xiaomi-aqara-button-and-google-home
+title: "Smart doorbell with Xiaomi Aqara button and Google Home"
+tags: [smart home, Aqara, Xaomi, Home Assistant]
+image: /img/blog/2019/02/doorbell.jpeg
+---
+
+So I have several Xiaomi Aqara buttons. Today I want to explain how to use this button as a smart doorbell that will play sound to your Google Home device through Home Assistant.
+
+<!-- truncate -->
+
+All my Aqara ZigBee devices are connected to Home Assistant via [ConBee II](https://phoscon.de/en/conbee2) and [deCONZ](https://www.home-assistant.io/integrations/deconz).
+
+First of all, let’s create a script that will be executed when the button is pressed. In your `scripts.yaml`:
+
+```yaml
+doorbell:
+  alias: Doorbell
+  sequence:
+  - data:
+      entity_id: media_player.googlehome4615 #Your Google Home device
+    service: media_player.turn_on
+  - delay: 00:00:03 #To make sure we are connected to Google Home
+  - data:
+      entity_id: media_player.googlehome4615 #Your Google Home device
+      media_content_id: https://your.homeassistant.domain:8123/local/doorbell.mp3
+      media_content_type: music
+    service: media_player.play_media
+  - delay: 00:00:05  #The same as doorbell.mp3 file ledgth
+  - data:
+      entity_id: media_player.googlehome4615
+    service: media_player.turn_off
+```
+
+To make `doorbell.mp3` available by that URL you need to place it to `/config/www` in your Home Assistant.
+
+Now we need to create a handler of the Aqara button in `automations.yaml`:
+
+```yaml
+- id: doorbell_notify
+  alias: Doorbell notify
+  trigger:
+  - entity_id: script.doorbell
+    from: 'off'
+    platform: state
+    to: 'on'
+  condition: []
+  action:
+  - data:
+      message: "Someone near your front door"
+    service: notify.push
+```

blog/2019-02-21-home-assistant-presence-detection-with-google-wifi/index.md

@@ -0,0 +1,137 @@
+---
+slug: home-assistant-presence-detection-with-google-wifi
+title: "Home Assistant presence detection with Google WiFi"
+tags: [smart home, Google WiFi, Home Assistant, home automation]
+image: /img/blog/2019/02/presence.jpeg
+---
+
+Previously my presence detection in Home Assistant works through Asus router and `asuswrt` component. And it was bad. Very bad. Recently I switched to Google WiFi and realized that the only way to implement presence detection with this router is IFTTT (Update: No). I thought it would be the slowest presence detection in the world but I was wrong.
+
+<!-- truncate -->
+:::info
+
+While you still can do this through IFTTT you need to know that there is much easier way not depending on your router model and any 3rd party services – [Nmap Tracker](https://www.home-assistant.io/integrations/nmap_tracker). You just enable this component and configure your devices IP addresses.
+I configured static IP addresses for devices I wanted to track using [DHCP IP Reservation](https://support.google.com/wifi/answer/6274660?hl=en) on Google WiFi router.
+
+:::
+
+If you still want to use IFTTT, you are welcome to continue reading.
+
+## Home Assistant IFTTT webhook
+
+First of all, we need to create a webhook for IFTTT in our Home Assistant instance through Integrations. Go to “Configuration” -> “Integrations” in the Home Assistant web UI. Find “IFTTT” in the “Set up a new integration” section and click “CONFIGURE”. You will be provided with a webhook URL to use in IFTTT applets. It should look similar to this:
+
+```
+https://ha.mydomain.com:8123/api/webhook/e7cd74856399e8934b8f5beffeeeaee4c351cdc8373647585ec040c7b69c2b999
+```
+
+Save this URL somewhere because you will not be able to see it again in your Home Assistant UI.
+
+## Home Assistant Entities
+
+For presence detection, I’m using `binary_sensors` with `device_class: presence`. Also, the state of those sensors depends on the corresponding `input_boolean`. It is made to be able to switch someone’s presence on and off manually by adding `input_boolean` to UI and switching its state. Don’t set the initial state for input_boolean. It will make it possible to save and restore its state on HA reboots. Also, I set these sensors to have different pictures depending on their presence.
+
+```yaml
+input_boolean:
+    is_yegor_home:
+      name: “Yegor’s presence”
+
+binary_sensor:
+  - platform: template
+    sensors:
+      presence_yegor:
+        friendly_name: "Yegor"
+        value_template: "{{ is_state('input_boolean.is_yegor_home', 'on') }}"
+        device_class: presence
+        entity_picture_template: "/local/yegor_picture_bw.jpg"
+```
+
+## IFTTT applets
+
+Next. There is an official Google WiFi service in IFTTT and it can create IF’s like “If some device connected/disconnected”. That’s exactly what we need.
+
+![Google WiFi in IFTTT](./ifttt_google_wifi.png)
+
+Open [IFTTT website](https://ifttt.com/) and log in with your account. Go to “My Applets” and click “New Applet” in the upper right corner.
+
+![image](./screenshot-ifttt.com-2019.02.21-11-10-25.png)
+
+Then hit “+this”, search for “Google WiFi” and click it. You will be asked to authorize IFTTT in your google account. After that you will be able to select one of the triggers Google WiFi can send to IFTTT:
+
+![image](screenshot-ifttt.com-2019.02.21-11-20-06.png)
+
+Let’s start with “Device connects”. Click it and select the device name you want to track in the next step.
+
+Next, you will be asked to create an action by clicking “+that”. For action, you need to find the “Webhooks” service and choose the only action it provides – “Make a web request”.
+
+Now we need to fill all the fields for web request:
+
+URL: `[The url of our Home Assistant webhook we created recently]`
+
+Method: `POST`
+
+Content Type: `application/json`
+
+Body: `{ "action": "call_service", "service": "input_boolean.turn_on", "entity_id": "input_boolean.is_yegor_home"}`
+
+## Handling IFTTT requests
+
+The last thing we need is to create a handler in Home Assistant for web requests from IFTTT. It will be new automation:
+
+```yaml
+- id: 'ifttt_webhook'
+  alias: IFTTT Webhook
+  trigger:
+    platform: event
+    event_type: ifttt_webhook_received
+    event_data:
+      action: call_service
+  action:
+    service_template: '{{ trigger.event.data.service }}'
+    data_template:
+      entity_id: '{{ trigger.event.data.entity_id }}'
+```
+
+This automation will handle any requests from IFTTT that will have `action: call_service` in their body with `service` and `entity_id` in it.
+
+For disconnecting from Google WiFi we need to create another applet in IFTTT. It will be the same except for two things:
+
+1. We should select “Device disconnects” from Google WiFi services when creating “+this” for applet.
+1. We need to replace input_boolean.turn_on with input_boolean.turn_off in web request’s “Body” field when creating “+that” to make it looks like this:
+
+```
+{ "action": "call_service", "service": "input_boolean.turn_off", "entity_id": "input_boolean.is_yegor_home"}
+```
+
+## Automation based on presence
+
+Assuming we’ve set up presence detection for everyone living in our home, we now need one variable to know if there is nobody home now. It would be helpful when creating automation that should be triggered when there is nobody home or when someone is back home. So we will add all our presence sensors in a group in `groups.yaml`:
+
+```yaml
+presence:
+    entities:
+        - binary_sensor.presence_someone
+        - binary_sensor.presence_yegor
+        - binary_sensor.presence_someone_else
+```
+
+Now we can rely on that group’s state to check if there is nobody home. I’ve added a delay of 10 minutes to make sure this automation will not be triggered when I simply reboot my device or there was a short connection lost to a router.
+
+```yaml
+- id: 'nobody_home'
+  alias: 'Nobody home'
+  trigger:
+  - entity_id: group.presence
+    for:
+      minutes: 10
+    from: 'on'
+    platform: state
+    to: 'off'
+  condition: []
+  action:
+  - data:
+      message: “Looks like there is nobody home now”
+    service: notify.push
+```
+
+That is all for now. Thanks for reading.

blog/2020-11-10-using-variables-as-configuration-for-home-assistant-automation/index.md

@@ -0,0 +1,211 @@
+---
+slug: using-variables-as-configuration-for-home-assistant-automation
+title: "Using variables as configuration for Home Assistant automation"
+tags: [smart home, Home Assistant, home automation]
+image: /img/blog/2020/11/variables.jpeg
+---
+
+Home Assistant 0.115 got the ability to use variables in automation and scripts. You can declare variables even using templates and use them across the script or automation.
+Here is an example from the release notes:
+
+```yaml
+automation:
+  trigger:
+    platform: sun
+    event: sunset
+    offset: -00:30
+  variables:
+    notification_service: notify.paulus_iphone
+  action:
+    - service: "{{ notification_service }}"
+      data:
+        message: Beautiful sunset!
+```
+<!-- truncate -->
+It is very useful and fun feature but at first I didn’t realize how powerful it is. Today I want to show you an example how you can use variables as some sort of configuration for automation to avoid creating a lot of `if`s and automation to handle identical tasks.
+
+I have a lot of ZigBee wall switches. Previously I had a separate automation to handle each of them. Every automation was handling:
+
+- First button press – toggle the lights with max brightness
+- Second button press – toggle the lights with low brightness
+- First button long press – increase the brightnress
+- Second button long press – decrease the brightness
+
+After implementing `variables` for automation I decided to store the mapping of device id, event (represents the button pressed and the type of press: long or short), corresponding brightness and light `entity_id` in `variables` like this:
+
+```yaml
+  variables:
+    device_map:
+      00:15:8d:00:02:cb:1a:9b:
+        light_entity_id: light.kitchen
+        brightness_buttons:
+          1001: -30
+          1002: 50
+          2001: 30
+          2002: 100
+      00:15:8d:00:02:c9:39:62:
+        light_entity_id: light.hallway
+        brightness_buttons:
+          1001: -30
+          1002: 55
+          2001: 30
+          2002: 100
+      00:15:8d:00:02:e9:fe:9e:
+        light_entity_id: light.living_room
+        brightness_buttons:
+          1001: 30
+          1002: 100
+          2001: -30
+          2002: 60
+      00:15:8d:00:02:cb:64:b4:
+        light_entity_id: light.hallway
+        brightness_buttons:
+          1001: 30
+          1002: 100
+          2001: -30
+          2002: 60
+      00:15:8d:00:02:c9:37:7d:
+        light_entity_id: light.bedroom
+        brightness_buttons:
+          1001: 30
+          1002: 100
+          2001: -30
+          2002: 24
+      00:15:8d:00:02:58:61:74:
+        light_entity_id: light.bathroom
+        brightness_buttons:
+          1001: 30
+          1002: 100
+          2001: -30
+          2002: 40
+```
+
+So now I can take the brightness value from my `device_map` by device id and event. Also, I can take `entity_id` of the light each wall switch should control.
+
+Also when I’m toggling the light I need to use `brightness_pct` service data to set the brightness, but when changing the brightness I need to use `brightness_step_pct`. So I added another variable to set the brightness service data name:
+
+```yaml
+variables:
+  brightness_attr: '{% if (trigger.event.data[''event''] == 2001) or (trigger.event.data[''event'']== 1001) %}brightness_step_pct{% else %}brightness_pct{% endif %}'
+```
+
+So when the button held the event is `2001` or `1001` (first and second button) and I need `brightness_step_pct`. I’m getting `brightness_pct` in another case.
+
+Now we can use all these variables in `action`:
+
+```yaml
+action:
+  - data:
+      '{{brightness_attr}}': '{{ device_map[trigger.event.data[''unique_id'']].brightness_buttons[trigger.event.data[''event'']]}}'
+      entity_id: '{{ device_map[trigger.event.data[''unique_id'']].light_entity_id}}'
+    service: light.{% if (trigger.event.data['event'] == 2001) or (trigger.event.data['event']== 1001) %}turn_on{% else %}toggle{% endif %}
+```
+
+Here we are using the most of variables – we are getting the right brightness value by the `unique_id` of our device and by the `event` that is representing the button and the type of press:
+
+```
+{{ device_map[trigger.event.data[''unique_id'']].brightness_buttons[trigger.event.data[''event'']]}}
+```
+
+Also, we are getting light `entity_id` by `unique_id` of the switch:
+
+```
+{{ device_map[trigger.event.data[''unique_id'']].light_entity_id}}
+```
+
+And the full automation:
+
+```yaml
+- id: wall_switch_handler
+  alias: Wall switch handler
+  trigger:
+  - event_data:
+      event: 1001
+    event_type: deconz_event
+    platform: event
+  - event_data:
+      event: 1002
+    event_type: deconz_event
+    platform: event
+  - event_data:
+      event: 2001
+    event_type: deconz_event
+    platform: event
+  - event_data:
+      event: 2002
+    event_type: deconz_event
+    platform: event
+  condition:
+  - condition: template
+    value_template: '{{''wall_switch'' in trigger.event.data[''id'']}}'
+  action:
+  - data:
+      '{{brightness_attr}}': '{{ device_map[trigger.event.data[''unique_id'']].brightness_buttons[trigger.event.data[''event'']]}}'
+      entity_id: '{{ device_map[trigger.event.data[''unique_id'']].light_entity_id}}'
+    service: light.{% if (trigger.event.data['event'] == 2001) or (trigger.event.data['event']
+      == 1001) %}turn_on{% else %}toggle{% endif %}
+  variables:
+    brightness_attr: '{% if (trigger.event.data[''event''] == 2001) or (trigger.event.data[''event'']
+      == 1001) %}brightness_step_pct{% else %}brightness_pct{% endif %}'
+    device_map:
+      00:15:8d:00:02:cb:1a:9b:
+        light_entity_id: light.kitchen
+        brightness_buttons:
+          1001: -30
+          1002: 50
+          2001: 30
+          2002: 100
+      00:15:8d:00:02:c9:39:62:
+        light_entity_id: light.hallway
+        brightness_buttons:
+          1001: -30
+          1002: 55
+          2001: 30
+          2002: 100
+      00:15:8d:00:02:e9:fe:9e:
+        light_entity_id: light.living_room
+        brightness_buttons:
+          1001: 30
+          1002: 100
+          2001: -30
+          2002: 60
+      00:15:8d:00:02:cb:64:b4:
+        light_entity_id: light.hallway
+        brightness_buttons:
+          1001: 30
+          1002: 100
+          2001: -30
+          2002: 60
+      00:15:8d:00:02:c9:37:7d:
+        light_entity_id: light.bedroom
+        brightness_buttons:
+          1001: 30
+          1002: 100
+          2001: -30
+          2002: 24
+      00:15:8d:00:02:58:61:74:
+        light_entity_id: light.bathroom
+        brightness_buttons:
+          1001: 30
+          1002: 100
+          2001: -30
+          2002: 40
+  initial_state: true
+  mode: parallel
+  max: 10
+```
+
+I have not only wall switches so I’m using template condition here to make sure the switch is the wall switch:
+
+```yaml
+  condition:
+  - condition: template
+    value_template: '{{''wall_switch'' in trigger.event.data[''id'']}}'
+```
+
+Also, this automation should be able to run in parallel to make it possible to handle several switch clicks at the same time in different rooms by different persons:
+
+```yaml
+  mode: parallel
+  max: 10
+```

blog/2020-12-29-bed-presence-detection-with-aqara-window-and-door-sensor-and-a-cheap-car-part/index.md

@@ -0,0 +1,43 @@
+---
+slug: bed-presence-detection-with-aqara-window-and-door-sensor-and-a-cheap-car-part
+title: "Bed presence detection with Aqara window and door sensor and a cheap car part"
+tags: [smart home, Home Assistant, home automation, DIY, Aqara, Xiaomi]
+image: /img/blog/2020/12/bed.jpeg
+---
+Bed presence detection could be very useful in home automation to control the lights and appliances you don’t need at night, but want to be ready in the morning. And today we will build a bed presence sensor out of a very universal device for DIY IoT. It is an Aqara ZigBee window and door sensor. Why it is so universal? Let’s take a closer look at its internals.
+
+<!-- truncate -->
+
+![internals](internals-1.jpg)
+
+See that little glass tube? That’s a [reed switch](https://en.wikipedia.org/wiki/Reed_switch). It operates under a magnetic field generated by the magnet inside the second part of the sensor. So, in general, it just closes the contact between two points of the electrical circuit. We can unsolder it and replace it with something else. A switch, for example. Or with a car seat pressure sensor, like this one:
+
+![Car seat sensor](seat_sensor.jpg)
+
+It could be found on Amazon or our favorite Chinese store just for 5$. It has two wires that could be closed or opened according to pressure presence. So all we need is to solder this sensor to the Aqara sensor’s board instead of the reed switch.
+
+![image](solder.jpg)
+
+I’ve removed the button cup from the top of the sensor to leave a hole for wires. Just remember to pair your sensor with whatever you are using as a ZigBee hub before doing this.
+
+![image](wires.jpg)
+
+All we need to do now is to put our new sensor under the mattress. I have a bed with wood slats that is narrower than the pressure sensor so I decided to put the sensor on a cardboard sheet
+
+![image](cardboard.jpg)
+
+I made two sensors to separately detect the bed presence of me and my wife. You need to experiment with the sensor position to get the most accurate results. Also, you need to remember that the “open” state of the sensor means “the bed is not occupied” and “closed” means that “the bed is occupied”.
+
+![Bed sensors in Home Assistant UI](bed_sensors.png)
+
+The third sensor on the screenshot is a Home Assistant [template binary sensor](https://www.home-assistant.io/integrations/binary_sensor.template/) that represents unconditional bed occupation. In other words, it is `on` when someone is in bed, and `off` otherwise:
+
+```yaml
+binary_sensor:
+  - platform: template
+    sensors:
+      bed_occupancy:
+        friendly_name: "Bed occupancy"
+        device_class: occupancy
+        value_template: "{{is_state('binary_sensor.bed_occupancy_door_side', 'off') or is_state('binary_sensor.bed_occupancy_window_side', 'off')}}"
+```

blog/2021-01-06-send-and-receive-sms-in-home-assistant-with-gsm-modem/index.md

@@ -0,0 +1,45 @@
+---
+slug: send-and-receive-sms-in-home-assistant-with-gsm-modem
+title: "Send and receive SMS in Home Assistant with GSM modem"
+tags: [smart home, Home Assistant, home automation, SMS, GSM]
+image: /img/blog/2021/01/modem.jpg
+---
+Yes, it is possible and you don’t need to build anything from sources. Sending SMS from your home could be useful, for example, to send emergency alerts. But what about receiving and parsing SMS messages? Well, I used it to integrate my car security system with my Home Assistant. Now my Home Assistant could start the engine of my car automatically to warm it up before driving to work.
+
+<!-- truncate -->
+
+First of all, we need to set up notification service via GSM modem following the official [documentation](https://www.home-assistant.io/integrations/sms). This will allow us to send SMS messages by calling the notify service, for example in automation action:
+
+```yaml
+action:
+  - service: notify.sms
+    data:
+      message: Hi!
+```
+
+But also this integration allows reading SMS messages sent to the modem phone number by listening to the `sms.incoming_sms` event.
+
+```yaml
+trigger:
+  - platform: event
+    event_type: sms.incoming_sms
+```
+
+![Automation trigger in UI](income_trigger.png)
+
+In automation `action`, we can now parse the message by searching keywords in it:
+
+```yaml
+action:
+  - choose:
+      - conditions:
+          - condition: template
+            value_template: >-
+              {{'engine is off' in trigger.event.data['text']}}
+        sequence:
+          -  ...
+```
+
+![Parsing action](parse_action.png)
+
+Here we are checking for the `engine is off` text in incoming SMS to perform some action. For example, to set the value of some `input_boolean`.

blog/2021-01-13-adding-wifi-power-control-to-an-integrated-amplifier/index.md

@@ -0,0 +1,107 @@
+---
+slug: adding-wifi-power-control-to-an-integrated-amplifier
+title: "DIY Smart Appliance: Adding WiFi power control to an integrated amplifier"
+tags: [smart home, Home Assistant, DIY, ESP8266, Wemos D1 Mini, WiFi, ESPHome]
+image: /img/blog/2021/01/ext.jpg
+---
+Previously I was using JBL Bar connected to a TV in my living room. It was controlled with WiFi IR bridge, so whenever my Chromecast or PS4 was in playing state, the Bar was turned on and ready.
+
+Now I have passive speakers with a simple integrated amplifier, and it can’t be turned on or off without physical interaction. You need to press and release the button on the front panel to toggle amplifier power. So today we will add WiFi power control to Cambridge Audion AXA25 integrated amplifier.
+
+<!-- truncate -->
+
+It is not a complex task to simulate button pressing. We just need a relay and a delay. But we also need to detect the amplifier state because there are no differences in turning on and turning off actions. Fortunately, my amplifier has a USB port on the back to power some USB devices. Putting something with an LED indicator in this port helped me to detect that the port is powered only when the amplifier is on. Digital pins of ESP8266 boards are good tools to detect the current presence on a USB port. We will need a 5V power line and a ground line from the port. Here is a pinout of the USB port:
+
+![USB pins](usb_pinout.png)
+
+Let’s draw!
+
+![](amp_diagram.png)
+
+## Components
+
+1. LOLIN (Wemos) D1 mini ([wemos.cc](https://www.wemos.cc/en/latest/d1/d1_mini.html))
+1. 5V Relay Brick by Itead ([itead.com](https://www.itead.cc/electronic-brick-5v-relay.html))
+1. AC-DC 220V to 5V Step-Down Mini Power Supply ([amazon](https://www.amazon.com/HLK-PM01-supply-module-intelligent-household/dp/B07G5GL4B8))
+
+Wemos has a [relay shield](https://www.wemos.cc/en/latest/d1_mini_shield/relay.html) as well but it can commutate up to 10A current so the electromagnet consumes more power. It is better to use some low-current relay for low-current circuits.
+
+As you can see I’m taking 220V AC power from the amplifier and converting it to 5V DC because we need to power the relay even when the amplifier is off. There is an always-powered low-current circuit that exists in the amplifier, but we can’t use it because of…. well, low current. Connecting a WiFi module and a relay to it will definitely destroy our amplifier.
+
+![Amplifier internals](int.png)
+
+## Firmware
+### MQTT
+If you want to use Arduino IDE to develop and flash the firmware to your Wemos D1 Mini board you’ll need to add an ESP8266 board manager and tools for Arduino. You can do this by performing [several simple steps from the official ESP8266 repository](https://github.com/esp8266/Arduino?ref=blog.yevi.org#installing-with-boards-manager). Then you can see the [MQTT-based firmware sources](https://github.com/estevez-dev/edwin-home/tree/master/devices/amplifier_mqtt) I was using before migrating to ESPHome. It could be an example, or you can just use it all.
+
+### ESPHome
+[ESPHome](https://esphome.io) actually makes such projects much easier to implement, improve and support. It also has a very reliable [Home Assistant plugin](https://github.com/esphome/hassio) and integration. That is why I moved all my DIY projects to ESPHome and here is a configuration file of my amplifier:
+
+```yaml
+esphome:
+  name: amplifier
+  platform: ESP8266
+  board: d1_mini
+
+wifi:
+  ssid: "****"
+  password: "**************"
+
+  # Enable fallback hotspot (captive portal) in case wifi connection fails
+  ap:
+    ssid: "Cambridge AXA25"
+    password: "*******"
+
+captive_portal:
+
+# Enable logging
+logger:
+
+# Enable Home Assistant API
+api:
+  password: "******"
+
+ota:
+  password: "******"
+
+binary_sensor:
+  - platform: gpio
+    id: amplifier_power
+    internal: true
+    pin:
+      number: D2
+      mode: INPUT_PULLDOWN_16
+
+switch:
+  - platform: gpio
+    id: relay
+    pin: D1
+    restore_mode: ALWAYS_OFF
+  - platform: template
+    name: "Amplifier"
+    id: amplifier
+    lambda: |-
+      if (id(amplifier_power).state) {
+        return true;
+      } else {
+        return false;
+      }
+    turn_on_action:
+      - if:
+          condition:
+            binary_sensor.is_off: amplifier_power
+          then:
+          - switch.turn_on: relay
+          - delay: 300ms
+          - switch.turn_off: relay
+    turn_off_action:
+      - if:
+          condition:
+            binary_sensor.is_on: amplifier_power
+          then:
+          - switch.turn_on: relay
+          - delay: 300ms
+          - switch.turn_off: relay
+```
+
+That’s it for today. Thanks for reading.

blog/2021-01-13-building-wifi-ir-remote-control-for-any-tv-with-esp8266-wemos-d1-mini-and-esphome/index.md

@@ -0,0 +1,240 @@
+---
+slug: building-wifi-ir-remote-control-for-any-tv-with-esp8266-wemos-d1-mini-and-esphome
+title: "Building WiFi IR remote control for any TV with ESP8266 Wemos D1 mini and ESPHome"
+tags: [smart home, Home Assistant, DIY, ESP8266, Wemos D1 Mini, WiFi, ESPHome]
+image: /img/blog/2021/01/tv_project.png
+---
+Many modern TVs can be controlled not only with an IR remote. Many could be easily integrated with Home Assistant or any other smart home solution. Samsung smart TVs, LG with WebOS… But what if your TV is so dumb it even don’t have WiFi or Bluetooth? Today we’ll add WiFi control to an old and dumb Samsung TV with a little help from ESPHome.
+
+<!-- truncate -->
+
+## Components and planning
+
+The base of our project would be [Wemos D1 mini](https://www.wemos.cc/en/latest/d1/d1_mini.html) – an ESP8266-based development board. Actually, it is possible to use any other WiFi development board you’d like, for example, NodeMCU. I choose the D1 mini because of its size and the nice [IR shield](https://www.wemos.cc/en/latest/d1_mini_shield/ir.html) it has. So the Wemos IR shield is the second part of our future IoT device. The main goal of the project is to receive commands through WiFi and transmit them to the TV using IR LED. So basically we want to build an IR remote where the buttons are replaced with commands through the WiFi.
+
+Also, we will need 5V DC power for our board. We can’t use a factory USB port on our TV because it is not powered when TV is off. I really like to use mini [AC-DC converters from Hi-Link](https://www.google.com/search?q=hi-link+mini+ac+dc+converter) in my projects and I really recommend it, but today I’ll need more power because I want to constantly power my Chromecast from the same power source. Because why not. So I found an old power supply that can handle up to 1.2A of current. Should be enough for a WiFi board and Chromecast.
+
+![Power supply](power_supply.jpg)
+
+Finally, we will also connect to the factory USB port of our TV. It is the best way to detect TV state (is it on or off currently).
+
+In general, the parts of the project should be connected like this:
+
+![Diagram](diagram.png)
+
+Now we will take a look at our TV from the inside.
+
+![Inside TV](inside_tv_1.jpg)
+
+## Build
+### Power Supply
+First of all, I removed the housing from my power supply. You don’t need to do this when using a Hi-Link power converter because it has places to solder the wires.
+
+![Power supply internals](power_supply_internals.jpg)
+
+I’ll use a USB port to connect Chromecast to it. Also, I’ll use USB port pins to take power for my WiFi board.
+
+![USB power pins](usb_power_pins.png)
+
+You need to be careful detecting 5V and Ground pins on the USB port. Here is a little help:
+
+![USB pinout](usb_pinout.png)
+
+From the other side of the power supply board, we have contact plates for AC power. That’s the place where we will solder AC power wires.
+
+![AC power contacts](ac_power_contacts.jpg)
+
+Our power supply is ready:
+
+![Power supply](power_supply_ready.jpg)
+
+### The board
+![D! min and shield](d1_mini_and_shield.jpg)
+
+We are ready to build the mainboard now. Wemos D1 mini and its shields come separately from the pin legs. It is a good opportunity to make our device as small as possible.
+
+![](pin_legs.jpg)
+
+But first, we need to solder some contacts on the IR shield. It has several IR LEDs as well as several options for a send pin. We will use only one IR LED – `IR4`, and `D3` digital pin for sending IR signal, so we need to solder contact plates on the IR shield like this:
+
+![Shield contacts](shield_contacts.png)
+
+![](ir4_led.png)
+
+![](micro_usb.png)
+
+:::tip
+
+You can use the same board and shield to get IR codes from your TV remote, or build a separate [IR receiver](/2021-01-15-ir-code-reader-with-esp8266-wemos-d1-mini-and-esphome/index.md). If you will use the same board, you need also to enable receiving LED on the IR shield by soldering the corresponding contact plates. For example, to enable the IR receiver on the `D4` pin:
+
+![](d4_ir_recv.png)
+
+:::
+
+Also, we don’t need such long pin legs so we can shorten it with wire cutters.
+
+![](short_legs.jpg)
+
+And solder the legs finally.
+
+Now the wires. We need 5V and ground from our power supply to be connected to 5V and ground pins of the WiFi board.
+
+![D1 power](d1_power-2048x1159.jpg)
+
+Also, we will need the wires to the factory USB port to detect the state of our TV. According to our plan, the 5V from the TV USB port will go to the `D2` pin of the Wemos board, and the ground should go to the ground pin.
+
+![USB power](usb_power.jpg)
+
+### The firmware
+
+We can make it ourselves. That is what I’ve done in the past. It was a solution that takes BASE64 encoded IR data through MQTT protocol, decodes it, and sends it to the IR led. ~~You can check it on my GitHub~~. I also had a [separate IR receiver](/2021-01-15-ir-code-reader-with-esp8266-wemos-d1-mini-and-esphome/index.md) to read IR codes from IR remotes and encode them using BASE64. You don’t need all these sources if you are using ESPHome. With ESPHome we will have a simple YAML config for our device:
+
+```yaml
+esphome:
+  name: living_room_tv
+  platform: ESP8266
+  board: d1_mini
+
+wifi:
+  ssid: "WiFi"
+  password: "************"
+
+  # Enable fallback hotspot (captive portal) in case wifi connection fails
+  ap:
+    ssid: "Living Room TV"
+    password: "************"
+
+captive_portal:
+
+# Enable logging
+logger:
+
+# Enable Home Assistant API
+api:
+  password: "************"
+  services:
+    - service: volume_up
+      then:
+        - remote_transmitter.transmit_samsung:
+            data: 0xE0E0E01F
+    - service: volume_down
+      then:
+        - remote_transmitter.transmit_samsung:
+            data: 0xE0E0D02F
+    - service: switch_source
+      then:
+        - remote_transmitter.transmit_samsung:
+            data: 0xE0E0807F
+    - service: hdmi1
+      then:
+        - remote_transmitter.transmit_raw:
+            carrier_frequency: 38029
+            code: [+4497,-4497,+552,-1657,+552,-1657,+552,-1657,+552,-552,+552,-552,+552,-552,+552,-552,+552,-552,+552,-1657,+552,-1657,+552,-1657,+552,-552,+552,-552,+552,-552,+552,-552,+552,-552,+552,-1657,+552,-552,+552,-552,+552,-1657,+552,-552,+552,-1657,+552,-1657,+552,-1657,+552,-552,+552,-1657,+552,-1657,+552,-552,+552,-1657,+552,-552,+552,-552,+552,-552,+552,-47858]
+    - service: hdmi2
+      then:
+        - remote_transmitter.transmit_raw:
+            carrier_frequency: 38029
+            code: [+4523,-4497,+552,-1709,+552,-1709,+552,-1709,+552,-579,+552,-579,+552,-579,+552,-579,+552,-579,+552,-1709,+552,-1709,+552,-1709,+552,-579,+552,-579,+552,-579,+552,-579,+552,-579,+552,-579,+552,-1709,+552,-1709,+552,-1709,+552,-1709,+552,-1709,+552,-579,+552,-1709,+552,-1709,+552,-579,+552,-579,+552,-579,+552,-579,+552,-579,+552,-1709,+552,-579,+552,-43993]
+
+ota:
+  password: "************"
+  
+remote_transmitter:
+  pin: D3
+  carrier_duty_percent: 50%
+  
+binary_sensor:
+  - platform: gpio
+    id: tv_power
+    internal: true
+    pin:
+      number: D2
+      mode: INPUT_PULLDOWN_16
+
+switch:
+  - platform: template
+    name: "Living Room TV"
+    id: living_room_tv
+    lambda: |-
+      if (id(tv_power).state) {
+        return true;
+      } else {
+        return false;
+      }
+    turn_on_action:
+      - if:
+          condition:
+            binary_sensor.is_off: tv_power
+          then:
+          - remote_transmitter.transmit_samsung:
+              data: 0xE0E040BF
+    turn_off_action:
+      - if:
+          condition:
+            binary_sensor.is_on: tv_power
+          then:
+           - remote_transmitter.transmit_samsung:
+              data: 0xE0E040BF
+```
+
+`remote_transmitter` is a part where we are declaring our [IR transmitter](https://esphome.io/components/remote_transmitter.html).
+
+`binary_sensor` is a sensor that will read the voltage from the TV USB port to tell its current state.
+
+`switch` section is our main functionality. It will be exposed as an entity in Home Assistant and will allow us to control our TV. As you can see from `lambda` it takes the state from `binary_sensor` and uses an IR transmitter to send IR “power” command to the TV when turned on or off. It also checks the state of `binary_sensor` before sending IR command to avoid turning off the TV when it was turned on several times, for example, from automation or service.
+
+`data` field for `remote_transmitter.transmit_samsung` can be discovered using a simple ESPHome [IR Receiver](/2021-01-15-ir-code-reader-with-esp8266-wemos-d1-mini-and-esphome/index.md) built with the same Wemos D1 mini and IR shield. You can even do it with the same board we are using for this project as was mentioned before.
+
+I also want to be able to control TV volume and switch input sources through WiFi. So I’ve added a `services` section in `api`. All those `services` would be exposed as `esphome` in Home Assistant.
+
+You can see `hdmi1` and `hdmi2` services have `transmit_raw` instead of `transmit_samsung`. This is because I don’t have such buttons on my TV remote to discover the codes so I found the codes in pronto hex format and was able to convert it to raw data with frequency detection using [IrScrutinizer](https://github.com/bengtmartensson/IrScrutinizer).
+
+That’s it. Compile it and flash it with [ESPHome Flasher](https://github.com/esphome/esphome-flasher?ref=blog.yevi.org).
+
+## TV
+### Placing the board
+Let’s find our TV IR receiver. Usually, it is where the red light is flashing on it. Disassembled my TV more I found it on the bottom edge. We need to put our WiFi board as close as possible to the TV IR receiver pointing our sending IR LED (`IR4`) in the direction of IR receiver.
+
+![The board placed inside TV](place-2048x1206.jpg)
+
+While the power from the power supply is not connected yet, we can power the board from a micro USB, power our TV and make the first test.
+
+:::danger
+
+You need to be extremely careful when powering on the appliance without its housing! Avoid touching the boards and other internal parts of the appliance because it can lead to appliance damage or your death!
+
+:::
+
+![Test run](test.gif)
+
+When trying to put the TV housing back on with the WiFi board inside I discovered that I need to make the device even smaller. So I removed IR receiving LED as I have an IR receiver as a separate device. Also, I was forced to solder all wires on the same side of the board.
+
+![Removed IR receiver](remove_receiver.jpg)
+
+![Change wires side](change_wires.jpg)
+
+Now we are ready to use our favorite tool – double-sided adhesive tape, to put the board in its constant living place.
+
+### Factory USB port
+
+Here it is on the factory board:
+
+![Factory USB port](factory_usb.png)
+
+On the other side of this board, we can find the pins where we will solder the wires from the WiFi board – one from `D2`, and the other from the ground.
+
+![Factory USB pins](factory_usb_pins.jpg)
+
+### Power
+
+Now let’s take a look at the AC power connector on the TV. We can find the pins on the opposite side of the board and solder AC wires from our power supply to it.
+
+![AC wires](ac_wires.jpg)
+
+Before placing our power supply inside the TV we need to make sure it is isolated from its metal body. I’ve put a layer of plastic under it.
+
+![Plastic film](plastic.jpg)
+
+So the overall picture is looking like this:
+
+![](overview.png)

blog/2021-01-15-ir-code-reader-with-esp8266-wemos-d1-mini-and-esphome/index.md

@@ -0,0 +1,88 @@
+---
+slug: ir-code-reader-with-esp8266-wemos-d1-mini-and-esphome
+title: "IR code reader with ESP8266 Wemos D1 mini and ESPHome"
+tags: [smart home, Home Assistant, DIY, ESP8266, Wemos D1 Mini, WiFi, ESPHome, IR]
+image: /img/blog/2021/01/shield.jpg
+---
+Quick step-by-step guide on assembling an IR receiver for reading IR codes from your remotes based on Wemos D1 mini, Wemos IR shield, and using ESPHome.
+
+<!-- truncate -->
+
+## Components used
+
+1. The housing from Broadling RM Pro+
+1. [Wemos D1 mini](https://www.wemos.cc/en/latest/d1/d1_mini.html) development board
+1. [Wemos IR shield](https://www.wemos.cc/en/latest/d1_mini_shield/ir.html)
+1. USB to micro-USB cable
+
+## Assembling
+First of all, we need to make our shield work with all transmitting LEDs and the pins we need. In this example, we will use `D3` for sending and `D4` for receiving.
+
+![](d4_ir_recv.png)
+
+![](shield_contacts_2.png)
+
+![](shield_contacts_1.png)
+
+Now lets put the board into the housing with cable connected and glue it all:
+
+![](d1_mini.jpg)
+
+Then put the shield on top:
+
+![](shield.jpg)
+
+Finally, close the housing:
+
+![](ready.jpg)
+
+## Using
+
+In ESPHome let’s create a config:
+
+```yaml
+esphome:
+  name: ir_receiver
+  platform: ESP8266
+  board: d1_mini
+
+wifi:
+  ssid: "WiFi"
+  password: "************"
+
+  # Enable fallback hotspot (captive portal) in case wifi connection fails
+  ap:
+    ssid: "IR Receiver"
+    password: "************"
+
+captive_portal:
+
+# Enable logging
+logger:
+  level: DEBUG
+
+# Enable Home Assistant API
+api:
+  password: "************"
+
+ota:
+  password: "************"
+
+remote_receiver:
+  pin:
+    number: D4
+    inverted: true
+  dump:
+    - samsung
+```
+
+As you can see it is set up to dump only Samsung-specific codes. You can read more about reading other codes on [esphome.io](https://esphome.io/components/remote_receiver.html). Also pay attention on `logger` section. It is set to `DEBUG` level.
+
+Compile, flash, open logs and start firing into our device with your IR remote. You’ll see something like this:
+
+```
+[17:34:48][D][remote.samsung:055]: Received Samsung: data=0xE0E007F8
+[17:34:51][D][remote.samsung:055]: Received Samsung: data=0xE0E020DF
+```
+
+You can now use this data with the ESPHome [Remote Transmitter](https://esphome.io/components/remote_transmitter.html) component to build, for example, something like [this](/2021-01-13-building-wifi-ir-remote-control-for-any-tv-with-esp8266-wemos-d1-mini-and-esphome/index.md).

blog/2021-01-15-using-stepper-motor-to-control-amplifier-volume-knob/index.md

@@ -0,0 +1,123 @@
+---
+slug: using-stepper-motor-to-control-amplifier-volume-knob-with-esp8266-and-esphome
+title: "Using stepper motor to control amplifier volume knob with ESP8266 and ESPHome"
+tags: [smart home, Home Assistant, DIY, ESP8266, Wemos D1 Mini, WiFi, ESPHome]
+image: /img/blog/2021/01/ext.jpg
+---
+My living room multimedia setup consists of numerous devices with varying degrees of stupidity. I’m chasing to improve it adding additional DIY hardware and functionality not always because of hate of TV remotes but also because I’m in love with IoT and soldering. First, I’ve added [WiFi power control to my Cambridge Audio amplifier](/2021-01-13-adding-wifi-power-control-to-an-integrated-amplifier/index.md), then I’ve implemented [WiFi-to-IR remote control to the TV](/2021-01-13-building-wifi-ir-remote-control-for-any-tv-with-esp8266-wemos-d1-mini-and-esphome/index.md). Then I decided to improve sound quality from TV and added a [DAC](https://wikipedia.org/wiki/Digital-to-analog_converter) between the TV and the amplifier. It is connected to the TV via [Toslink](https://wikipedia.org/wiki/TOSLINK) optical cable. And it broke my volume control because you can’t change the volume on a digital output port on a TV, you forced to rotate the knob on amplifier instead.
+
+<!-- truncate -->
+
+ saw several solutions to this problem.
+
+1. The easiest, but boring and expensive, is to purchase an improved model of my amplifier with IR remote control.
+2. Сheap and the one that looks right is to add a digital potentiometer to the amplifier input and control it with Wemos D1 mini I already have in my amp.
+3. Most inaccurate but fancy and the one you will use to impress your family and friends is to add a stepper motor that will rotate the knob for you.
+
+I think you already guessed the way I choose, so let’s see how I achieved this.
+
+![](gif.gif)
+
+## Components
+As I already have Wemos D1 mini and a relay in my amplifier, you could see more components than you expect on photos, but, for simplicity, I’ll list only those components used to control the knob in this article.
+
+1. WEMOS (LOLIN) D1 mini WiFi board ([wemos.cc](https://www.wemos.cc/en/latest/d1/d1_mini.html))
+2. AC-DC 220V to 5V Step-Down Mini Power Supply ([amazon](https://www.amazon.com/HLK-PM01-supply-module-intelligent-household/dp/B07G5GL4B8))
+3. ULN2003 stepper motor driver
+4. 5V 28BYJ-48 stepper motor
+
+### Connections
+
+- 5V DC power from power supply, 5V pin of Wemos D1 mini and +5V input of motor driver are connected together.
+- Ground of the power supply, GND pin of Wemos D1 mini and -5V (ground) of motor driver are also connected together.
+- IN1 of motor driver -> D5 on Wemos
+- IN2 of motor driver -> D6 on Wemos
+- IN3 of motor driver -> D7 on Wemos
+- IN4 of motor driver -> D8 on Wemos
+
+:::note
+
+At the moment of writing ESPHome supported only two types of stepper motor drivers. See ESPHome [documentation](https://esphome.io/components/stepper/index.html) for more info.
+
+:::
+
+## Building
+The AC-DC power supply was connected to the AC power input of the amplifier.
+
+![Power connection](power.png)
+
+Now to the knob. The knob actually rotates an analog [potentiometer](https://wikipedia.org/wiki/Potentiometer) – a mechanical component with variable resistance. On my amplifier, all potentiometers have a hexagonal-shaped hole on the other side of the rotating element:
+
+![](hole.jpg)
+
+This made the connection of the motor as easy as a couple of rasp strokes. I mean the shaft of my motor was slightly bigger than the hole on the potentiometer so I took a rasp and made it smaller. Then I used a couple of plastic racks with nuts and a bunch of hot glue to anchor the motor on amp housing.
+
+![](shaft.jpg)
+
+![](motor_top.jpg)
+
+![](motor_side.jpg)
+
+I know it is not the best binding but it works. I don’t think this solution is permanent because I relay want to use digital potentiometers instead. I made this more for fun, but currently, this is the only way to remotely control the volume in my living room. Just to give you an opportunity to change your mind before you start a similar project (or, who knows, maybe to improve it) here is a list of issues it currently has:
+
+- It is impossible to determine the current motor position because its position resets on each boot.
+- It is easy to brake reduction gears in motor and even the amp when rotating the potentiometer further than it could.
+- It is hard to rotate the knob manually because you need to rotate the motor as well.
+
+If you are still here lats go to the software part.
+
+## ESPHome
+
+ESPHome could rotate your stepper motors with [Stepper Component](https://esphome.io/components/stepper/index.html). Here is my stepper config in ESPHome:
+
+```yaml
+stepper:
+  - platform: uln2003
+    id: volume_motor
+    pin_a: D5
+    pin_b: D6
+    pin_c: D7
+    pin_d: D8
+    sleep_when_done: true
+    max_speed: 250 steps/s
+    acceleration: inf
+    deceleration: inf
+```
+
+The idea is to change the volume on a given relative amount of motor steps. This will simplify the adjustment to find the right volume step for you. I declared a new service in `api` section of my `amplifier.yaml`:
+
+```yaml
+api:
+  password: "*************"
+  services:
+    - service: set_volume
+      variables:
+        target: int
+      then:
+        - stepper.report_position:
+            id: volume_motor
+            position: 0
+        - stepper.set_target:
+            id: volume_motor
+            target: !lambda 'return target;'
+```
+
+It would be exposed in Home Assistant as `esphome.amplifier_set_volume` service and will take the only parameter `target`. So in automation action increasing the volume in my case is looking like this:
+
+![Automation action](action.png)
+
+Or in YAML:
+
+```yaml
+service: esphome.amplifier_set_volume
+data:
+  target: 50
+```
+
+Decreasing the volume action is the same, but with negative `target`:
+
+```yaml
+service: esphome.amplifier_set_volume
+data:
+  target: -50
+```

blog/2023-10-31-hosting-ghost-blog-on-synology-nas/index.md

@@ -0,0 +1,122 @@
+---
+slug: hosting-ghost-blog-on-synology-nas
+title: Hosting Ghost Blog On Synology NAS
+tags: [self-hosting, homelab, Synology NAS, Ghost]
+image: /img/blog/2023/10/synonas.webp
+---
+Do you want to know how and where RandomPlace is hosted? Or do you just want to know how to host a [Ghost](https://ghost.org) blog on your Synology NAS? I'm here today to answer both questions.
+
+:::info
+
+This post is from the past. From far away times when this website had another domain, another name and another hosting place. For current setup, please see [HomeLab](/docs/homelab).
+
+Still, this guide can be useful.
+
+:::
+<!-- truncate -->
+
+It's been a long way to my current home lab configuration. There were several Intel NUCs, Nextcloud, and so on, but at the end (or just for now) I have Synology NAS and it allows me to host not only my personal cloud but other services as well. This blog is one of them.
+
+RandomPlace blog is running in the Docker container. In Synology DSM it is a [Container Manager](https://www.synology.com/en-us/dsm/feature/container-manager) package. To be honest, I'm not a big fan of the everything-in-containers approach. Bare-metal installation is much better in terms of maintainability and flexibility, but it is clear why Docker containers become so popular across our home labs. It is much easier to get something up and running with a single command instead of resolving dependencies and configuring your OS. So when this blog was hosted on Intel NUC with Ubuntu OS, it was not in containers. Now, with a new-for-me DSM software, it is easier to get something up and running with a single command instead of resolving dependencies and configuring my OS =)
+
+I know there is a way to run NodeJS apps on Synology DSM, but this is something I need to discover. I'm also not sure I'm ready to SSH to my NAS and start to edit system files. Stability is the main reason why I'm currently with Synology.
+
+Let's get back to our main topic. All further instructions are from DS423+ and DSM 7.2. But I'm sure it would be the same for many other NASes.
+
+## Prepare
+
+First of all, we will need a **Container Manager** package to be installed from the Package Center
+
+![](001.png)
+
+Then we will need some folders to be created. After installing a Container Manager, you will have a new shared folder created for you: `docker`. A good place to put all your container's data in. We should create a new directory there with any name you want. For example `blog`. This would be the root of our future project. Then, let's create a `content` directory inside it:
+
+![](002.png)
+
+Lastly, we will need to know the volume number where our directories are placed. For this open **File Station**, right-click on the docker folder and choose **Properties**. The **Location** property in my case tells me that the docker folder is placed on a `volume1`.
+
+![](003.png)
+
+## The Database
+
+The Ghost requires the MySQL database to work. For the database, we have two options. The first is to have a database as a separate docker container. This option is the simplest. Another one is to use the **MariaDB** Synology package to have a single database service for all your projects. This will require us to install the **phpMyAdmin** as well to create and manage databases and users. This option enables the ability for a simple database backup solution because the **MariaDB** package with all data and settings could be included in **Hyper Backup**. Also, we will avoid having several containers with the same database service in the future.
+
+With the second option, after installing **MariaDB** and **phpMyAdmin** from the **Package Center** on our NAS, let's log in to **phpMyAdmin** with the root user and password we set upon installation and create a new database for our blog and name it, for example, "my_blog":
+
+![](004.png)
+
+Now we will need to create a user for this database. Choose your newly created database on the left and navigate to the **Privileges** tab. You can find the "Add user account" link there.
+
+Selecting "Any host" for the "Host name" field upon user creation will allow the Ghost container to connect to the database even from the bridged network. But also allows connection from any host within your local network (assuming that you didn't open MySQL port to the public internet which you shouldn't do in any case).
+
+Don't forget to tick "Grant all privileges on database my\_blog." on the same user creation page.
+
+![](005.png)
+
+Hit **Go** in the bottom and we are done here.
+
+## Create
+
+Now the time has come to create a new project in **Container Manager**. Launch it, open the **Projects** view from the left, and hit the **Create** button.
+
+Here we need to give our project a name, choose a previously created path for it, and provide a `docker-compose.yml`.
+
+![](006.png)
+
+And here is our `docker-compose.yml`:
+
+```yaml
+version: '3.1'
+
+services:
+  ghost:
+    image: ghost:5.71.0 # Choose the version here: https://hub.docker.com/_/ghost/
+    container_name: the_blog_ghost
+    restart: unless-stopped
+    ports:
+      - 43332:2368 # Some random port mapped to a default Ghost port inside container
+    volumes:
+    # This is the path to our directory created at the beginning, mapped to a content directory inside the container
+      - /volume1/docker/blog/content:/var/lib/ghost/content
+    environment:
+      database__client: mysql
+      database__connection__host: 192.168.1.2 #This should be the local IP address of your NAS
+      database__connection__user: blog_ghost #Database user we've created previously
+      database__connection__password: '12345' #The strongest password you can imagine 
+      database__connection__database: my_blog #Database name we've created previously
+      url: https://blog.randomplace.online #Your future blog domain, you definitely already bought
+```
+
+The next step will allow us to create a web portal for our container on a port we mentioned in `docker-compose.yml`
+
+![](007.png)
+
+We should accept this option and hit **Next** and then **Done** to start the container and navigate to a **Web Station** to configure a Web Portal:
+
+![](008.png)
+
+Here we need to create a Name-based portal and use our domain as a Hostname. Also, we should force HTTPS (redirect all HTTP requests to a secure HTTPS connection) with the HSTS option:
+
+![](009.png)
+
+The last thing we should do is generate a new SSL certificate to serve our blog through HTTPS.
+
+:::info
+
+Your domain name should already be pointed to your NAS's public IP address for the certificate generation.
+
+:::
+
+Go to **Control Panel - Security** and choose the **Certificate** tab. Here we can request a new free SSL certificate by clicking the Add button and choosing "Add new certificate".
+
+![](010.png)
+
+Then "Get a certificate from Let's Encrypt" and fill in some fields:
+
+![](011.png)
+
+You'll get an email notification on the address added here when there will be time to renew your free certificate.
+
+After certificate generation, we should open Settings on the same Certificates tab, find our domain service, and choose the newly generated certificate for it.
+
+That's it!

blog/2023-12-19-monitor-usb-ups-connected-to-synology-nas-in-home-assistant/index.md

@@ -0,0 +1,46 @@
+---
+slug: monitor-usb-ups-connected-to-synology-nas-in-home-assistant
+title: "Monitor USB UPS connected to Synology NAS in Home Assistant"
+tags: [self-hosting, homelab, Synology NAS, UPS, Smart Home, Home Assistant]
+image: /img/blog/2023/12/upsha.png
+---
+There is a lot of automation you can do with this data, but today I want to write up a short guide on how to safely get the information from the UPS connected to your NAS via USB into the Home Assistant.
+
+<!-- truncate -->
+
+There is a lot of automation you can do with this data, but today I want to write up a short guide on how to safely get the information from the UPS connected to your NAS via USB into the Home Assistant.
+
+:::info
+
+Your Synology NAS and Home Assistant should be in the same local network, or you'll need an additional network configuration that is not a subject of this post
+
+:::
+
+## UPS server
+After connecting the UPS to the NAS we need to enable Synology NAS UPS server that will allow other machines to get UPS information over the local network. In your Synology DSM go to _Control Panel -> Hardware & Power -> UPS_ tab. Here you can set up a UPS connected to your NAS via USB (or via SNMP protocol if you have enterprise-grade UPS for data centers). Assuming you did that, it is time to enable the UPS server by checking the _"Enable network UPS server"_ checkbox.
+
+![](001.png)
+
+Also, you need to click the _"Permitted Synology NAS Devices"_ button and add your Home Assistant local IP address there:
+
+![](002.png)
+
+After that, you need to make sure the port for the UPS server is open in the firewall on your NAS. Go to _Control Panel -> Security -> Firewall_ tab and click the _"Edit rules"_ button. Here you need to edit an existing rule for the _TCP_ protocol that has a list of apps in the _Ports_ column:
+
+![](003.png)
+
+In the editing window click the Select button near _"Select from a list of built-in applications"_ and make sure the _UPS server_ is selected:
+
+![](004.png)
+
+## Home Assistant integration
+
+The integration that will allow us to connect to the UPS server on Synology NAS is [Network UPS Tools](https://www.home-assistant.io/integrations/nut/).
+
+In your Home Assistant go to _Settings -> Devices & services_ and click the _"Add integration"_ button. Search for "nut" there and choose _"Network UPS Tools (NUT)"_.
+
+![](005.png)
+
+In the configuration window that appeared you need to set your NAS's local IP address as a _Host_ and leave the _Port_ number unchanged.
+
+Hit _Submit_ and you are done.

blog/2023-12-19-restart-or-shutdown-your-proxmox-node-from-home-assistant-automation/index.md

@@ -0,0 +1,57 @@
+---
+slug: restart-or-shutdown-your-proxmox-node-from-home-assistant-automation
+title: "Restart or shutdown your Proxmox node from Home Assistant automation"
+tags: [self-hosting, homelab, Proxmox, Smart Home, Home Assistant]
+image: /img/blog/2023/12/power_switch.jpg
+---
+There is a [UPS monitoring through NUT](/2023-12-19-monitor-usb-ups-connected-to-synology-nas-in-home-assistant/index.md) configured in my Home Assistant. So I decided my Home Assistant could shut down my homelab servers on a low UPS battery.
+
+<!-- truncate -->
+
+We will use [Proxmox VE API](https://pve.proxmox.com/wiki/Proxmox_VE_API) and Home Assistant [RESTful Command](https://www.home-assistant.io/integrations/rest_command/) integration for this.
+
+## Proxmox user and permissions
+
+Let's do things right and don't allow Home Assistant to log in with the root user to your Proxmox environment. We will create a _role_ first. Go to your _Datacenter_ view in Proxmox web UI choose _Permissions -> Roles_ and hit _Create_.
+
+We will create a `PowerManager` role with `Sys.PowerMgmt` privileges. This will allow our user to execute shutdown/restart commands through Proxmox API, but nothing more.
+
+![](001.png)
+
+Next, we will create a user. In Proxmox web UI go to _Permissions -> Users_ and hit _Add_. Give him a username and password, and choose _"Proxmox VE authentication server"_ as a _Realm_:
+
+![](002.png)
+
+Next, we will go to our _Datacenter_ view in Proxmox web UI choose _Permissions_ and hit _Add_. Here, we will set `/nodes/<node_name>` as the Path, select our newly created _User_ and our newly created _Role_ for him:
+
+![](003.png)
+
+Lastly, we will need an API token to make API calls. For this, we will go to _Permissions -> API_ Tokens and click _Add_. Choose our newly created user, give the token an ID, and disable _Privilege Separation_.
+
+![](004.png)
+
+After clicking _Add_ we will see the token. We need to write down the token ID and token itself to use it in Home Assistant later.
+
+## Home Assistant integration
+
+Now to the Home Assistant. We will need to edit our `configuration.yaml` file as currently, this is the only way to add RESTful Command integration. Here is an example:
+
+```yaml
+rest_command:
+  spacedock_one_shutdown:
+    url: "https://192.168.99.3:8006/api2/json/nodes/spacedock-one/status"
+    method: post
+    headers:
+      Authorization: PVEAPIToken=pwrmngr@pve!power=73892874-ad34-4b98-83e2-7be787f9bee3
+    content_type: "application/x-www-form-urlencoded"
+    payload: "command=shutdown"
+    verify_ssl: false
+```
+
+The `url` should have the next format: `https://<proxmox node IP>:8006/api2/json/nodes/<proxmox node name>/status`.
+
+The authorization header should have the next format: `PVEAPIToken=<proxmox username>@pve!<API token ID>=<API token>`
+
+You can use `shutdown` or `reboot` as a `command`.
+
+After restarting Home Assistant you will have a new service available. In our example, it would be `rest_command.spacedock_one_shutdown`. Calling it will do the trick.

blog/2025-02-15-wireguard-tunnel-from-ubuntu-vps-to-homelab-through-unifi-vpn-server/index.md

@@ -0,0 +1,108 @@
+---
+slug: wireguard-tunnel-from-ubuntu-vps-to-homelab-through-unifi-vpn-server
+title: "WireGuard tunnel from Ubuntu VPS to HomeLab through UniFi VPN server"
+tags: [self-hosting, homelab, WireGuard, VPN]
+image: /img/blog/2025/02/tunnel.jpg
+---
+I'm not surprised people prefer Tailscale over WireGuard. Did you see the WireGuard [quick start guide](https://www.wireguard.com/quickstart/)? Did you try to connect using this guide? Anyway, I have a VPS on Hetzner I wanted to connect to my local network through a secure tunnel. Tailscale is nice, but why set up a new infrastructure when I have one inside my UniFi Cloud Gateway Ultra?
+
+<!-- truncate -->
+
+:::warning
+
+This guide will work for you only if you have a static WAN IP
+
+:::
+
+So first of all I went to _Settings -> VPN_ on my UniFi Cloud Gateway Ultra, switched to a _VPN Server_ tab, and added a new Wireguard VPN server. I let UniFi decide on the client's IP range.
+
+Then I added a client, which will be my VPS. And downloaded a WireGuard interface config file there:
+
+![](001.png)
+
+Then I connected to my VPS through SSH to make some Linux command line magic.
+
+:::note
+
+I need to mention here that I'm writing this guide a long time after the actual setup. So unfortunately I can't remember the sources I found tips and tricks to make this work. But it works now for me and can help to make it work for you, my dear reader.
+
+:::
+
+On my VPS I have Ubuntu 24.04 installed.
+
+So, to the command line. Install WireGuard:
+
+```bash
+sudo apt install wireguard
+```
+
+Create a config file:
+
+```bash
+sudo nano /etc/wireguard/wg0.conf
+```
+
+Insert the configuration downloaded from the UniFi VPN client creation step:
+
+```
+[Interface]
+PrivateKey = ***************************************
+Address = 192.168.4.2/32
+DNS = 192.168.4.1
+
+[Peer]
+PublicKey = ***************************************
+AllowedIPs = 0.0.0.0/0
+Endpoint = ***.***.**.**:51821
+```
+
+Now edit it to look like this:
+
+```
+[Interface]
+PrivateKey = ***************************************
+Address = 192.168.4.2/32
+PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
+PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
+ListenPort = 51820
+
+[Peer]
+PublicKey = ***************************************
+AllowedIPs = 192.168.4.0/24,192.168.50.0/24,192.168.1.0/24
+Endpoint = ***.***.**.**:51821
+PersistentKeepalive = 10
+```
+
+`PostUp` and `PostDown` are commands to be executed when the WireGuard network interface connects or disconnects. In my case, this is to add and remove `iptables` rules for WireGuard traffic routing through the default network interface.
+
+`AllowedIPs` should be edited to your needs. Here is my needs:
+
+- `192.168.4.0/24` allows access to any IP address on the same subnet as the VPS would be placed after connecting
+- `192.168.50.0/24` allows access to any IP on my other subnet
+- `192.168.1.0/24` allows access to any IP on my main subnet (I'm not sure about this, but anyway the access is blocked on the UniFi Firewall level)
+
+These rules are loose because the Firewall on my UniFi Gateway blocks any cross-subnet traffic anyway allowing only limited communications.
+
+This should be enough to bring the connection up with `wg-quick`:
+
+```bash
+sudo wg-quick up wg0
+```
+
+To see the status:
+```bash
+sudo wg show
+```
+
+And now to make it work through server reboots we need to down the interface:
+
+```bash
+sudo wg-quick down wg0
+```
+
+And up it back with a system service, also enabling it:
+```bash
+sudo systemctl start wg-quick@wg0 && sudo systemctl enable wg-quick@wg0
+```
+
+Further interface control should be performed through `systemctl` as well like `systemctrl stop`, `systemctl restart` or `systemctl status`.

blog/2025-05-21-make-one-proxmox-node-to-wol-another/index.md

@@ -0,0 +1,101 @@
+---
+slug: make-one-proxmox-node-to-wol-another
+title: "Make one Proxmox node to wake-on-lan another"
+tags: [self-hosting, homelab, Proxmox, WOL]
+image: /img/homelab.png
+---
+Nothing is eternal, especially the relevance of documentation. I think help.ubuntu.com is an absolute winner, holding the largest number of outdated and irrelevant pages. But that's not a topic for today's post.
+One of my Proxmox cluster nodes can't power itself on after the outage. But it supports wake-on-LAN, so I decided that another node could power it on. And the simplicity of this task was overrated by me.
+
+<!-- truncate -->
+
+:::warning
+
+Wake on LAN doesn't work across VLANs. Magic packets could be sent and received only inside a single subnet.
+
+:::
+
+## The victim
+
+First of all, even after enabling "Wake up on PCI event" or something in BIOS it was not working because WoL was still disabled on a software level. It can be checked with: 
+
+```bash
+ethtool enp1s0
+```
+
+Where `enp1s0` is a physical network interface of a Proxmox node, not a bridge.
+
+There should be `Wake-on:` setting among others. In my case it was `Wake-on: d`, which means that wake-on-LAN is disabled, according to `ethtool` documentation:
+
+```
+p  Wake on phy activity
+u  Wake on unicast messages
+m  Wake on multicast messages
+b  Wake on broadcast messages
+a  Wake on ARP
+g  Wake on MagicPacket(tm)
+s  Enable SecureOn(tm) password for MagicPacket(tm)
+d  Disable (wake on nothing).  This option clears  all  previous
+    options.
+```
+
+We need to set it to wake by the MagicPacket(tm). We need to create a config file for this to be enabled on system start. But first we need to:
+
+```bash
+ip link show enp1s0
+```
+
+and write down our network device MAC address. Then create a file:
+
+```bash
+nano /etc/systemd/network/90-wakeonlan.link
+```
+
+with the next content:
+
+```
+[Match]
+MACAddress=<mac-address-here>
+
+[Link]
+NamePolicy=kernel database onboard slot path
+MACAddressPolicy=persistent
+WakeOnLan=magic
+```
+
+After that we need to reboot and check WOL status again:
+
+```bash
+ethtool enp1s0
+```
+
+Now `Wake-on` should be set to `g`.
+
+## The one who bothering
+
+On another node we need to install an util that will be sending a magic packet:
+
+```bash
+apt update
+apt install etherwake
+```
+
+Now we can power the victim off and try to wake it with:
+
+```bash
+etherwake -i vmbr0 <mac_address>
+```
+
+Where `vmbr0` is a bridge network interface of current Proxmox node, and `<mac_address>` is a MAC address of the victim's physical network interface.
+
+If it works, we can now add a cron job to wake our victim upon current node startup, adding some delay to make sure the network is ready:
+
+```bash
+crontab -e
+```
+
+Cron job line to add:
+
+```
+@reboot sleep 30s && /usr/sbin/etherwake -i vmbr0 <mac_address>
+```

docs/homelab/index.md

@@ -1,9 +1,29 @@
 ---
 sidebar_position: 1
+title: Overview
 ---
 
-# What is it?
+## What is it?
 
-This is my project of publicly available documentation of my home servers and services.
+This is my project of publicly available documentation of my home servers and self-hosted services.
 
-Working on it...
+## Network
+
+The gate to my HomeLab is a **UniFi Cloud Gateway Ultra**. It is connected to a **1 Gbps** fiber optic from my ISP and manages **3 static WAN IP** addresses.
+
+The local network is separated into **four VLANs**.
+
+The gateway is also a DNS server for all local network and VPN clients.
+
+WiFi network is delivered by **two UniFi U6+** access points powered with the **Switch Lite 8 PoE**.
+
+[More on network](network.md)
+
+## Servers
+My family home cloud is provided by the **Synology DS423+**. It is for photos and documents hosting and sharing.
+
+I also have a **DIY NAS with TrueNAS Community Edition** on it that hosts most of the services for personal and family use, that are not from Synology.
+
+The third one is the **Asus PN42** min PC with an Intel N100 CPU with the **Proxomox VE** on it. It hosts public services, like this website, my Gitea instance, and others.
+
+I also have a mighty **Home Assistant Blue** with... well **Home Assistant** on it. It does not depend on other servers and has a separate Cloudflare tunnel to it from the outside to be available even when all other servers fail.

docs/homelab/network.md

@@ -0,0 +1,84 @@
+---
+title: Network
+---
+## WAN
+
+### Port forwarding
+
+```mermaid
+---
+config:
+  look: handDrawn
+  theme: neutral
+---
+flowchart LR
+    W8[WAN IP *8]
+    W9[WAN IP *9]
+    W0[WAN IP *0]
+    montgomery("`Synology NAS
+    _DSM Web UI, Hyper Backup Vault, Drive Server_`")
+    plex(Plex external access)
+    ingress50("`ingress-50
+    _Zoraxy_`")
+    ingress1("`ingress-1
+    _Zoraxy_`")
+    WAN1 --> W8
+    WAN1 --> W9
+    WAN1 --> W0
+    W8 --> montgomery
+    W8 --> plex
+    W8 --> qbt(qBittorrent)
+    W9 --> gitssh(Gitea SSH)
+    W9 --> ingress50 --> pub(Public services)
+    W0 --> ingress1 --> per(Personal services)
+```
+
+### Firewall rules
+In addition to default rules.
+
+| Name                      | Action | Source Zone   | Destination Zone |
+|-------------------------- | ------ | ------------- | ---------------- |
+| Allow UniFi remote access | Allow  | External      | Gateway          |
+
+## Local network
+### VLANs
+| Name        | Subnet            | Description                                                   | Isolate network |
+|------------ | ----------------- | ------------------------------------------------------------- | --------------- |
+| **Default** | _192.168.1.0/24_  | Default local network for laptops, family phones and tablets  | No              |
+| **Pub**     | _192.168.50.0/24_ | An isolated VLAN for public services                          | No              |
+| **Guest**   | _192.168.5.0/24_  | An isolated VLAN for guest WiFi access                        | No              |
+| **IoT**     | _192.168.6.0/24_  | An isolated VLAN for connected home appliance                 | No              |
+
+- Device Isolation is disabled for all networks
+
+### Firewall zones
+| Name            | Built in | Networks / Interfaces                       |
+|---------------- | -------- | ------------------------------------------- |
+| Internal        | ✅       | [`Default`](#vlans)                         |
+| External        | ✅       | [`Primary (WAN1)`](#wan) `Secondary (WAN2)` |
+| Gateway         | ✅       | -                                           |
+| VPN             | ✅       | [`Hearthstone`](#vpn) [`VPS`](#vpn)         |
+| Hotspot         | ✅       | [`Guest`](#vlans)                           |
+| DMZ             | ✅       | -                                           |
+| VLAN 50         | ❌       | [`Pub`](#vlans)                             |
+| VLAN 6          | ❌       | [`IoT`](#vlans)                             |
+
+### Zones access rules
+Additional Firewall rules allowing or blocking zone-to-zone or subnet-to-subnet communications.
+
+| Source Zone   | Destination Zone | Source                | Destination                 | Action             | Description                                                                        | 
+|-------------- | ---------------- | --------------------- | --------------------------- | ------------------ | ---------------------------------------------------------------------------------- |
+| Internal      | VLAN 50          | All                   | All                         | Allow with return  | Allow all traffic from [`Default`](#vlans) network to [`Pub`](#vlans)              |
+| Internal      | VLAN 6           | All                   | All                         | Allow with return  | Allow all traffic from [`Default`](#vlans) network to [`IoT`](#vlans)              |
+| VPN           | Internal         | [VPS subnet](#vpn)    | All                         | Allow only return  | Allow return traffic from [`VPS`](#vpn) subnet to [`Default`](#vlans)              |
+| VPN           | Internal         | [VPS subnet](#vpn)    | All                         | Block              | Block [`VPS`](#vpn) VPN clients from accessing the [`Default`](#vlans) network     |
+| VPN           | Hotspot          | [VPS subnet](#vpn)    | All                         | Block              | Block [`VPS`](#vpn) VPN clients from accessing the [`Guest`](#vlans) network       |
+| VPN           | DMZ              | [VPS subnet](#vpn)    | All                         | Block              | Block [`VPS`](#vpn) VPN clients from accessing the [`DMZ`](#firewall-zones) zone   |
+| VPN           | VLAN 50          | All                   | [Hearthstone](#vpn)         | Allow all          | Allow [`Hearthstone`](#vpn) VPN clients access to [`Pub`](#vlans) network          |
+| VPN           | VLAN 6 (IoT)     | All                   | [Hearthstone](#vpn)         | Allow all          | Block [`Hearthstone`](#vpn) VPN clients access to [`IoT`](#vlans) network          |
+| VLAN 50       | VLAN 50          | All                   | All                         | Allow all          | Allow [`Pub`](#vlans) network clients accessing each other                         |
+
+## VPN
+There are two Wireguard servers configured:
+1. **Hearthstone**. Subnet _192.168.3.0/24_. For external access to all local networks.
+1. **VPS**. Subnet _192.168.4.0/24_. For accessing VPS servers as local network devices.

docusaurus.config.js

@@ -36,6 +36,20 @@ const config = {
     locales: ['en'],
   },
 
+  markdown: {
+    mermaid: true,
+  },
+
+  themes: ['@docusaurus/theme-mermaid'],
+
+  scripts: [
+    {
+      src: 'https://plausible.nicelycomposed.codes/js/script.outbound-links.js',
+      defer: 'true',
+      'data-domain': 'yevi.org',
+    },
+  ],
+
   presets: [
     [
       'classic',
@@ -48,8 +62,13 @@ const config = {
           showReadingTime: true,
           feedOptions: {
             type: ['rss', 'atom'],
+            title: "Yehor Vialov's Blog",
+            description: 'Some notes, interesting things and projects',
+            copyright: 'Copyright © ${new Date().getFullYear()} Yehor Vialov',
             xslt: true,
           },
+          blogSidebarTitle: 'Timeline',
+          blogSidebarCount: 0,
           // Useful options to enforce blogging best practices
           onInlineTags: 'warn',
           onInlineAuthors: 'warn',
@@ -102,6 +121,14 @@ const config = {
                 label: 'Blog',
                 to: '/blog',
               },
+              {
+                label: 'Blog RSS feed',
+                to: 'pathname:///blog/rss.xml',
+              },
+              {
+                label: 'Blog Atom feed',
+                to: 'pathname:///blog/atom.xml',
+              },
             ],
           },
           {
@@ -146,6 +173,7 @@ const config = {
       prism: {
         theme: prismThemes.github,
         darkTheme: prismThemes.dracula,
+        additionalLanguages: ['bash'],
       },
     }),
 };

package.json

@@ -1,6 +1,6 @@
 {
   "name": "yevi-org",
-  "version": "0.0.2",
+  "version": "0.1.0",
   "private": true,
   "scripts": {
     "docusaurus": "docusaurus",
@@ -16,6 +16,7 @@
   "dependencies": {
     "@docusaurus/core": "3.7.0",
     "@docusaurus/preset-classic": "3.7.0",
+    "@docusaurus/theme-mermaid": "^3.7.0",
     "@mdx-js/react": "^3.0.0",
     "clsx": "^2.0.0",
     "prism-react-renderer": "^2.3.0",
@@ -41,4 +42,4 @@
   "engines": {
     "node": ">=18.0"
   }
-}
+}

sidebars.js

@@ -17,9 +17,8 @@
 const sidebars = {
 
   homelabSidebar: [{
-    type: 'doc',
-    id: 'homelab/index',
-    label: 'HomeLab',
+    type: 'autogenerated',
+    dirName: 'homelab',
   },],
 
 

src/components/HomepageFeatures/index.js

@@ -3,16 +3,6 @@ import Heading from '@theme/Heading';
 import styles from './styles.module.css';
 
 const FeatureList = [
-  {
-    title: 'HomeLab Documented',
-    link: 'docs/homelab',
-    Svg: require('@site/static/img/homelab.svg').default,
-    description: (
-      <>
-        Here I'm trying my best in documenting my home servers and services.
-      </>
-    ),
-  },
   {
     title: 'Blog',
     link: 'blog',
@@ -23,7 +13,16 @@ const FeatureList = [
       </>
     ),
   },
-
+  {
+    title: 'HomeLab Documented',
+    link: 'docs/homelab',
+    Svg: require('@site/static/img/homelab.svg').default,
+    description: (
+      <>
+        Here I'm trying my best in documenting my home servers and self-hosted services.
+      </>
+    ),
+  },
 ];
 
 function Feature({ Svg, title, link, description }) {

src/css/custom.css

@@ -15,6 +15,8 @@
   --ifm-color-primary-lightest: #6d266d;
   --ifm-code-font-size: 95%;
   --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);
+  --ifm-footer-link-hover-color: #b07ab0;
+  --ifm-link-color: var(--ifm-color-primary-lightest)
 }
 
 /* For readability concerns, you should choose a lighter palette in dark mode. */
@@ -27,5 +29,5 @@
   --ifm-color-primary-lighter: #c196c1;
   --ifm-color-primary-lightest: #d1b2d1;
   --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3);
-}
-
+  --ifm-link-color: var(--ifm-color-primary-darker);
+}

src/pages/deleted-post.md

@@ -0,0 +1,15 @@
+---
+title: This post was removed
+description: A message about removed content
+hide_table_of_contents: true
+---
+
+# You probably got here visiting a link somewhere on the internet
+
+Sorry to say, but this post was removed because of one of the reasons (or because of all of them):
+- It was critically outdated
+- It was misleading
+- It was stupid
+- It has no historical value
+
+You can check my [other blog posts](/blog) or start from the [home page](/).