u/alessandroadorna

Hi everyone, looking for some advice on two related issues.

The problem:

I have two Hisense split AC units from 2017. One of them has now failed for the second time with a burnt electronic control board (external unit). The app diagnostic shows two errors: external unit error and external control panel/compressor error. The technician confirmed the external motor doesn't start, but the reversing valve responds to commands — meaning there's partial communication between internal and external board.

Interestingly, two years ago I replaced the same AC's board for the same reason. No other devices in my home have ever been damaged by voltage issues, so my electrician friend thinks it might just be poor reliability of Hisense boards rather than a grid overvoltage problem.

My current setup:

- Single-phase 230V Italian grid

- 12-module DIN rail panel (fully occupied)

- eMylo EAI-90 WiFi energy meter

- Home Assistant on Synology NAS

- 2x Shelly Plus 1PM already available to install in the AC wall boxes

What I'm considering:

Replacing the eMylo with a Shelly Pro EM-50 (2-channel energy meter with built-in overvoltage protection, auto cut-off and automatic restore when voltage returns to normal).

Alternatively, adding a dedicated Finder 70.11.8.230.2022 voltage monitoring relay on the DIN rail. I checked the datasheet and it seems to support automatic reconnection when voltage returns to the normal range — but I'm not 100% sure. Does this relay auto-restore power without manual intervention, or does it require a physical reset on-site?

To fit the Pro EM-50 (4 DIN modules) I'd need to free up 2 extra slots — my electrician suggested replacing 4 standard 2-module breakers with Siemens 1-module equivalents.

My questions:

1. Is the Hisense board failure likely a grid issue or just poor component quality?

2. Is the Shelly Pro EM-50 sufficient as overvoltage protection, or should I also add a dedicated voltage monitoring relay?

3. Does the Finder 70.11.8.230.2022 auto-restore power automatically, or does it need manual reset?

4. Any experience with Shelly Pro EM-50 and Home Assistant integration?

Thanks!

Hi everyone,

I'm running OPNsense 26.1.6 on a Zimaboard 2 (single-board PC) and I need help setting up proper DNS-based content filtering on a dedicated VLAN.

My setup:

- OPNsense 26.1.6 on Zimaboard 2

- Netgear GS716T managed switch

- Ubiquiti UAP-AC-Lite access point (managed via UniFi Controller on Docker)

- VLAN 4: 192.168.8.0/22 (OPT1 interface)

- Clients on VLAN 4 are iOS devices (iPhone/iPad) and Android devices

Goal:

I want clients on VLAN 4 to be able to access only one specific website (which uses Akamai CDN — already whitelisted) and have all other internet traffic blocked. The idea is to use DNS filtering: Unbound should resolve only the allowed domains and return NXDOMAIN for everything else.

What we've done so far:

- Configured Unbound with a custom view that uses local-zone: ... transparent for the allowed domains and relies on the default refuse behavior for everything else

- Added access-control-view: 192.168.8.0/22 to /var/unbound/etc/access_lists.conf

- Set up firewall rules on OPT1 to allow DNS, HTTP and HTTPS

- Fixed a NAT redirect issue (DNS was being redirected to a wrong IP)

The problem:

Every time OPNsense restarts or Unbound is reloaded via the GUI, it overwrites /var/unbound/etc/access_lists.conf and removes our access-control-view directive. We tried using a syshook script to reapply the config after boot, but the script was killing the OPNsense-managed Unbound process and replacing it with a manually launched one — which caused other issues.

Question:

What is the correct and persistent way to add a custom Unbound view with access-control-view in OPNsense without it being overwritten on reload? Is there a supported template directory or hook we should use?

Thanks in advance!

UPDATE: SOLVED (maybe) :-)

After a lot of investigation, here is what we found and how we fixed it.

There were actually two separate issues:

1. DNS redirect pointing to wrong IP

The Destination NAT rule for DNS on OPT1 was redirecting queries to an old IP address (from a previous interface configuration) instead of the current OPT1 gateway. This meant all DNS queries from VLAN 4 clients were going nowhere. Fix: update the redirect target IP in Firewall > NAT > Destination NAT.

2. Persistent custom Unbound configuration

The correct and persistent way to add custom Unbound configuration in OPNsense (including views and access-control-view) is to work directly with the template system:

- Template files are located in /usr/local/opnsense/service/templates/OPNsense/Unbound/core/

- The file +TARGETS defines which template files get copied and where

- Files listed in +TARGETS are copied to /usr/local/etc/unbound.opnsense.d/ and then at startup copied to /var/unbound/etc/ by the start.sh script

- Since /var/unbound/etc/*.conf is included inside the server: block of unbound.conf, your custom files must NOT contain a server: directive

What we did:

- Edited access_lists.conf template to remove the server: line at the top and added our access-control-view directive at the bottom

- Created a new XXXXXXXX.conf template file containing our custom view definition, ending with local-zone: "." refuse to block all unlisted domains

- Added the new file to +TARGETS so it gets deployed automatically

- After reboot, everything persists correctly

Hope this helps someone else facing the same issue!