Wiznet makers

PHEILIX TECHNOLOGY Residential EMS Solution: https://bexenergysolution.rs/all-in-one-solarni-sistem.pdf 

BEX ENERGY SOLUTIONS: https://bexenergysolution.rs Using Pheilix technology Solutions. 

Title

Pheilix “Residential Solar + Battery + EV Charger All-in-One”: A home microgrid EMS that connects PV, storage, loads, and EVSE—and puts a WIZnet W5500 on the controller’s Ethernet path

Introduction

Repo: https://www.pheilix.com 

This project is a product-focused, engineer-readable walkthrough of Pheilix’s Residential EMS “Solar + Battery + EV Charger” all-in-one solution, based primarily on the brochure PDF you attached. The point isn’t just to bundle three devices; it’s to run a coordinated control loop across PV generation, battery charge/discharge, household loads, and EV charging, then expose that whole system through a cloud/app stack (OCPP included). The brochure also explicitly shows WIZnet’s W5500 inside the integrated controller’s schematic—so we can describe exactly where Ethernet sits in the architecture and why a wired link matters in a home-energy control product.

Access check (required)

https://www.pheilix.com/ — Not accessible from this environment (ClientResponseError).

https://bexenergysolution.rs/ — Not accessible from this environment (ClientResponseError).

https://bexenergysolution.rs/all-in-one-solarni-sistem.pdf — Not accessible from this environment (ClientResponseError).

Because of that, this article is written from the uploaded brochure PDF (and avoids guessing about anything that would require the websites).

Overview

Pheilix frames the solution as an “integrated control device” for a residential microgrid: PV + inverter + storage + EV charging + home loads, all monitored and controlled in one system. The brochure’s language is very “systems engineering”: it talks about communication, data collection, analysis, calculation, adjustment, and “reasonable distribution” of energy among the subsystems—i.e., an EMS that actually balances the household, not just monitors it.

One practical emphasis is load balancing for EV charging. EVSE power can be dynamically adjusted based on inverter output, household load, and grid power—so you can push EV charging when there’s surplus PV/storage and back off when the house or grid constraints tighten.

Quick background

Residential energy gets hard the moment EV charging enters the picture. EVSE is usually the largest flexible load in the home, and optimizing “PV self-consumption” becomes a real-time control problem:

How much PV is available now?

How much load is the house consuming?

What’s the battery state (SOC, charge/discharge power, next-day needs)?

Can we charge the EV now without triggering peak limits or wasting PV?

Pheilix’s approach is to consolidate the above into a single control device, then add a cloud/app layer for monitoring, remote control, scheduling, and even firmware upgrades across multiple components.

Company & ecosystem

Repo: https://www.pheilix.com 

What kind of company is Pheilix (as evidenced by the brochure)

The brochure positions Pheilix as doing independent R&D and shipping a SaaS cloud platform + app system alongside the hardware. It reads more like a “platform + controller + field devices” vendor than a single-product charger manufacturer.

What activity signals show up

The brochure repeatedly describes the solution in modular “system blocks” (communications module, algorithm module, EVSE control, inverter/storage management, fault processing, data storage, HMI, cloud platform service). That’s a fairly strong signal that Pheilix is pitching not just components but an integrated architecture that partners/installers can deploy.

Where influence typically spreads (and how BEX fits)

Since both the Pheilix and BEX websites were inaccessible here, I can’t verify the exact listing you saw on BEX. But your discovery path makes sense: solutions like this often spread through local energy solution providers / installers / resellers who package PV + ESS + EVSE as a single “home energy system” offer. The brochure itself supports that “packaged deployment” mindset by listing a full stack of system parts and accessories.

Architecture & data flow (mechanism-first)

AI Generated Image

1) Sense & collect: bring PV/ESS/EVSE/load data into one controller

The brochure describes a communication module that pulls data from multiple peripherals:

PV inverter + energy storage battery via RS485 or CAN 2.0B to read PV generation, battery charge/discharge power, remaining capacity, inverter grid/off-grid status, and fault data.

Charging infrastructure (EVSE) via RS485 or Ethernet to read working status, charging power, and faults.

It also “draws load power,” implying metering/measurement inputs that let the controller reason about household consumption.

Just as importantly, the same communications layer is used to send control commands back out (mode switching for inverter, battery, and EVSE).

2) Decide: algorithm + load-balancing drive real-time EV power control

The brochure describes an algorithm module with an AI angle (peak/valley policy, charging demand, battery energy state). The most concrete control loop is load balancing:

Compute “available remaining charging power” based on inverter output, household load power, and grid power.

Adjust EV charging power in real time accordingly.

It also mentions using weekly weather data pushed from the cloud to guide battery charge/discharge strategy (charge off-peak, discharge peak, manage surplus).

3) Act: control EVSE scheduling + inverter/storage operating modes

The architecture includes explicit control blocks:

EVSE control module: power control + schedule management (start/pause/stop).

Inverter and battery management: real-time mode switching; manage off-peak charging to ensure next-day household + EV needs.

4) Observe & operate: fault handling, logging, HMI, cloud/app

Operationally, the brochure describes:

Fault processing that receives faults from peripherals and raises alarms for troubleshooting.

Data storage that logs operational status for inverter/battery/EVSE/CT equipment plus control records and fault logs; store locally in controller FLASH and upload to the cloud DB; optionally export via USB/serial to PC storage.

HMI module with LCD touch screen to display whole-home microgrid status and allow manual mode switching, EV power limits, and stop charging.

Cloud platform service enabling Internet connectivity via Wi-Fi, wired network, or 4G; using TCPIP/websocket/OCPP to connect to Pheilix’s OCPP cloud server and the Pheilix Smart app; remote monitoring and remote access, plus remote firmware upgrades (controller / EVSE / inverter / battery).

WIZnet / Ethernet section (where WIZnet is used, and why it’s there)

The brochure’s integrated controller schematic explicitly labels W5500 on the controller board, in the same “network/OCPP Internet” pathway as the system’s cloud connectivity.

Mechanically, that implies a very specific design choice:

The controller is a hub for noisy, field-facing interfaces (RS485, CAN), plus local HMI and logging.

To tie that local control plane into cloud/app operations (OCPP server connectivity, web/app access, remote upgrades), the controller exposes a wired Ethernet path—and WIZnet’s W5500 is the named Ethernet device in the schematic.

In a residential installation, wired Ethernet is often the “boring but reliable” backbone when you need always-on connectivity for monitoring, troubleshooting, and updates—especially in garage/utility-room environments where Wi-Fi can be inconsistent. Pheilix’s architecture (cloud + app + remote upgrades) benefits directly from that reliability, and the brochure makes W5500 part of that story at the hardware level.

Results / lessons learned / limitations

The brochure frames this as a real EMS (not a bundle): the value proposition is integration + protocol unification + control, especially for EV load balancing under PV/storage constraints.

The design is clearly “stacked”: field interfaces → controller logic → HMI/logging → cloud/app → remote upgrade workflows.

Limitation: this is a brochure-level description. For deployment-grade engineering you’d still want: supported inverter/ESS compatibility lists, security specifics for cloud connectivity (e.g., TLS configuration for OCPP/websocket), certification details, and wiring/topology guidance beyond the brief schematic.

Where this matters (who should care)

PV + ESS installers who want to add EV charging without turning every job into a one-off integration project

OT/embedded engineers designing home-energy controllers that must bridge RS485/CAN field devices with Ethernet + cloud/OCPP operations

EVSE operators moving into residential offerings where “charger-only” isn’t enough and energy-aware charging is the differentiator

Quick reproduce / getting started (engineering checklist)

Define the control objective: maximize PV self-consumption, peak shaving, off-grid resilience, EV-priority charging, or a mix.

Confirm peripheral interfaces: inverter/ESS protocol and physical layers (RS485 vs CAN), EVSE interface (RS485 vs Ethernet).

Decide what “load power” measurement means in your installation (whole-home meter vs sub-meter/CT approach).

Choose the backhaul strategy: Wi-Fi only vs wired Ethernet default vs 4G fallback—aligned with your monitoring/OTA expectations.

Validate cloud/app boundaries: monitoring-only vs remote control/scheduling vs firmware upgrade flows across controller + EVSE + inverter + battery.

Related UCC & VAR: 

VAR 1(OCPP Module): https://maker.wiznet.io/matthew/resellers/full%2Dfeatured%2Docpp%2Dmodule%2Docpp/ 

VAR 2(EV Charger): https://maker.wiznet.io/ronpang/resellers/smartwall%2Dev%2Dcharger/ 

Title

Pheilix “Residential Solar + Battery + EV Charger All-in-One”: 집 안의 마이크로그리드를 한 번에 묶는 EMS — 그리고 컨트롤러 이더넷에 WIZnet W5500을 넣은 이유

PHEILIX TECHNOLOGY Residential EMS Solution: https://bexenergysolution.rs/all-in-one-solarni-sistem.pdf 

BEX ENERGY SOLUTIONS: https://bexenergysolution.rs Using Pheilix technology Solutions. 

Introduction

본 프로젝트는 Pheilix Technology의 주거용 Solar + Battery + EV Charger 올인원(Residential EMS Solution) 브로셔를 기반으로, 왜 이들이 “태양광/배터리/EV 충전기/가정 부하”를 단순 패키징이 아니라 단일 제어기(컨트롤러)와 단일 앱/클라우드로 통합 운영하려 하는지, 그리고 그 통합을 구현하는 **통신·데이터 흐름(특히 RS485/CAN/Ethernet/OCPP)**을 엔지니어 관점에서 정리한 제품 소개 아티클입니다. 이 과정에서 브로셔의 회로/블록도에 WIZnet W5500 이더넷 칩이 명시되어 있어, “올인원 EMS 컨트롤러가 왜 유선 이더넷(=W5500)을 필요로 하는가”까지 메커니즘으로 설명합니다.

Overview

이 솔루션이 겨냥하는 문제는 꽤 현실적입니다. 기존 주거용 태양광 시스템은 “낮에 남는 전기를 계통으로 보내고, 밤에는 계통에서 사온다”가 기본 흐름이고, 배터리를 넣으면 “낮에 남는 전기를 저장해 밤에 쓴다”까지는 됩니다. 그런데 EV 충전이 들어오면 이야기가 달라집니다. EV는 가정에서 가장 큰 가변 부하가 될 수 있고, “태양광/배터리/부하/EV” 사이에서 지금 이 순간 어떤 전기가 어디로 흘러가야 가장 효율적인지를 계산하고 제어해야 합니다.

Pheilix는 현재 시장의 한계를 “각 장치(인버터/ESS/EVSE)가 서로 다른 프로토콜과 앱으로 따로 놀고, 실시간으로 상호 관계 데이터를 모으기 어려워 최적 배분이 불가능하다”로 요약합니다. 그래서 올인원의 핵심은 “3개를 한 박스에 넣는 것”이 아니라, 통합 제어장치가 모든 장치를 ‘읽고’(모니터링) ‘명령’(제어)해 에너지 흐름을 조율하는 구조입니다.

Quick background

주거용 마이크로그리드에서 통합 EMS가 어려운 이유는 보통 3가지입니다.

계측의 분해능(visibility): 집 전체 전류만 보거나 일부 CT만으로는 “가정 부하가 PV를 쓰는지, 계통을 쓰는지”를 비율까지 나누기 어렵습니다.

프로토콜의 파편화: PV 인버터, 배터리(ESS/BMS), EV 충전기(EVSE)는 인터페이스가 다르고, 제조사 앱도 분리되어 있습니다.

제어의 타이밍: 피크/오프피크 요금제, EV 충전 요구, 배터리 SOC, 태양광 예측까지 고려하면 “충전 전력을 실시간으로 조절”하는 로드 밸런싱이 필요합니다.

Pheilix는 이 문제를 “통합 컨트롤러 + AI 알고리즘 + 클라우드(OCPP) + 앱”으로 푸는 방향을 제시합니다.

Author & Community (이 회사는 어떤 회사인가 / 활동 / 파급력)

Pheilix Technology는 어떤 회사인가

브로셔 관점에서 Pheilix는 자신들을 Residential EMS 솔루션 제공자로 포지셔닝하며, “독립 R&D”와 “SAAS Cloud Platform & App System(브로셔 이미지상 AWS 기반 표기)”을 강조합니다. 즉, 하드웨어(컨트롤러/EVSE)만 파는 게 아니라, 운영 플랫폼(클라우드)과 앱까지 포함한 스택을 함께 제안하는 형태입니다.

웹(검색 인덱스로 확인 가능한 페이지)에서도 “Pheilix Smart”라는 이름으로 OCPP 1.6/2.0 기반 클라우드 플랫폼과 앱을 제공하며, 충전 세션/소켓 상태/요금제/빌링 설정 등 “충전 네트워크 운영자” 관점의 기능을 설명합니다. 앱은 다국어 지원을 강조합니다.

파급력이 생기는 지점(어디서 확산되나)

이 타입의 제품은 오픈소스 커뮤니티에서 퍼지기보다, 설치·유통 파트너(리셀러/시공사) 채널을 통해 확산됩니다. 당신이 언급한 BEX ENERGY SOLUTIONS 같은 사이트가 대표적인 “유입 경로”입니다.

BEX는 사이트에서 태양광 시스템/EV 충전기/배터리 스토리지를 카테고리로 내걸고, “완전 통합된 시스템 + 앱 기반 제어” 내러티브를 사용합니다. 또한 뉴스/행사(예: 친환경 포럼 참여) 형태로 대외 활동을 올리면서 지역 시장에서 인지도를 쌓는 모습이 보입니다. 즉, Pheilix 같은 올인원 EMS가 실제 현장에 들어가는 경로는 “제조사 단독”보다 로컬 에너지 솔루션 사업자(설치/운영)의 포트폴리오로 들어가는 경우가 많습니다.

Architecture & Data Flow (메커니즘)

브로셔가 제시하는 통합 제어장치(Integrated control device)는 “통신 모듈 + 알고리즘(AI) + EVSE 제어 + 인버터/배터리 관리 + 장애 처리 + 데이터 저장 + HMI + 클라우드 연동”의 구성으로 설명됩니다. 이를 데이터 흐름으로 풀면 다음과 같습니다.

1) 수집(Communication module): 현장 장치 데이터를 “하나의 컨트롤러”로 모은다

PV 인버터/배터리(ESS)로부터 RS485 또는 CAN 2.0B(CAN HD) 인터페이스로 데이터를 읽습니다. (발전량, 배터리 충·방전 전력, SOC, 인버터 계통연계/독립 여부, 장애 데이터 등)

EV 충전기(EVSE)로부터는 RS485 또는 Ethernet으로 상태/충전 전력/장애 정보를 가져옵니다.

동시에 “부하 전력(load power)”도 가져와, 태양광·배터리·부하·EV 사이 관계를 계산할 수 있게 합니다.

2) 판단(Algorithm module): 로드 밸런싱 + 요금 정책 + 예측을 합친 제어

브로셔는 “피크/밸리(시간대별 요금) 정책, EV 충전 요구, 배터리 에너지 상태”를 고려하는 AI 알고리즘을 언급합니다.

핵심 제어는 로드 밸런싱입니다. 인버터 출력, 가정 부하 전력, 계통 전력 등을 기반으로 “지금 남는 충전 가능 전력”을 계산해 EV 충전 전력을 실시간으로 올렸다 내립니다.

3) 실행(Control modules): EVSE 충전 전력과 인버터/배터리 모드를 실제로 바꾼다

EVSE 제어 모듈은 통신 모듈을 통해 충전 전력을 제어하고, 충전 스케줄(시작/일시정지/중지)을 관리합니다.

인버터/배터리 관리 모듈은 인버터 모드를 실시간으로 전환하고, 오프피크 시간대 충전/미충전 정책으로 “다음 날 가정 부하 + EV 수요”를 맞추려는 전략을 설명합니다.

장애 처리 모듈은 각 장치에서 들어오는 장애를 받아 알람을 띄우고 문제 해결을 돕는 방향으로 설계됩니다.

4) 기록(Data storage)과 운영(HMI/Cloud): 로컬 로그 + 클라우드 업로드

운영 데이터(인버터/배터리/EVSE/CT485 등), 제어 이력, 장애 로그를 컨트롤러 내부 FLASH에 저장하고, 동시에 클라우드 DB로 업로드한다고 적혀 있습니다. 필요 시 USB/시리얼을 통해 로컬 PC/USB 드라이브로 옮길 수 있다고도 합니다.

HMI는 15인치 LCD 터치로 전체 홈 마이크로그리드 상태를 보여주고, 수동 모드 전환/충전 전력 제한/충전 중지 등의 조작을 지원합니다.

클라우드는 Wi-Fi/유선 네트워크/4G 등으로 인터넷에 연결하고, TCPIP / websocket / OCPP 같은 프로토콜로 Pheilix OCPP 클라우드 서버와 “Pheilix Smart App”에 붙는 형태로 설명됩니다. 원격 모니터링뿐 아니라 펌웨어 원격 업그레이드까지 언급됩니다.

WIZnet / Ethernet Section (WIZnet이 어디에, 어떻게 쓰였나)

이 브로셔에서 WIZnet 사용은 “추정”이 아니라 명시되어 있습니다.

사용된 WIZnet 제품

통합 컨트롤러(Residential EMS Controller) 블록도에 W5500이 명확히 표기되어 있으며, RJ45(유선 이더넷) 경로로 “OCPP Internet”에 연결되는 구성으로 그려져 있습니다.

어떻게 사용되나(메커니즘)

컨트롤러는 현장 장치들과는 RS485/CAN 등 산업용 필드 인터페이스로 얽히고, 외부(클라우드/OCPP 서버/앱)로는 **유선 이더넷이 ‘메인 백홀(backhaul)’**이 됩니다.

이때 W5500은 MCU가 TCP/IP 기반 통신(브로셔는 TCPIP/websocket/OCPP)을 수행할 수 있도록 이더넷 인터페이스를 제공하는 역할을 합니다.

브로셔의 설계 철학을 그대로 따르면, W5500 기반 유선 이더넷은 다음 상황에서 특히 유리합니다.

Wi-Fi 품질이 불안정한 가정/차고/분전반 환경에서도 **상시 접속(Always-On)**이 필요한 경우

원격 모니터링과 더불어 펌웨어 OTA/원격 유지보수가 중요한 경우

OCPP 기반으로 EV 충전 운영과 연동해야 하는 경우(“충전기 단품”이 아니라 EMS 전체가 클라우드와 함께 움직일 때)

즉, 이 올인원에서 WIZnet W5500은 “옵션 통신”이 아니라, 통합 제어장치가 클라우드/앱으로 나가는 핵심 네트워크 경로를 담당하는 구성요소로 등장합니다.

Results / Lessons learned / Limitations

이 브로셔가 던지는 메시지는 명확합니다. “태양광+배터리+EV 충전”을 진짜로 최적화하려면, 결국 부하까지 포함한 통합 EMS가 필요하고, 그 EMS는 “장치 프로토콜 통합 + 로드 밸런싱 + 클라우드 운영”까지 스택으로 가져가야 합니다.

기술적으로 가장 설득력 있는 부분은 “통신 모듈이 모든 장치 데이터를 모으고, 알고리즘이 EV 충전 전력을 실시간 조절한다”는 로직이 구체적으로 적혀 있다는 점입니다.

한계도 있습니다. 브로셔는 개념/블록도 중심이라, 실제 프로젝트에서는 지원 인버터/배터리/EVSE 프로토콜 호환 리스트, OCPP 버전/보안(TLS, 인증), CT485 구성과 계측 정확도, 배선/규격 인증 같은 구현 디테일을 추가로 확인해야 합니다.

Where this matters (누가 보면 좋은가)

주거용 태양광/ESS 시공사 중, 이제 EV 충전까지 ‘통합 운영’으로 묶어 차별화하려는 팀

EV 충전 사업자 중, 주거 시장에서 “충전기 단품”이 아니라 가정 에너지 최적화(EMS)까지 포함해 서비스하려는 팀

임베디드/OT 엔지니어: RS485/CAN 기반 현장장치와 클라우드(OCPP)를 잇는 컨트롤러 아키텍처가 필요한 팀

Quick Reproduce / Getting Started (엔지니어용 체크리스트)

목표 정책부터 결정: “자가소비 최대화” vs “피크 억제” vs “백업(오프그리드)” vs “EV 우선”

현장 인터페이스 정리: 인버터/배터리/EVSE가 RS485? CAN? Ethernet? 어떤 조합인지

로드 밸런싱 입력 신호 확정: 그리드 미터/CT(CT485)로 어디를 측정할지(전체 vs 분기)

백홀 선택: Wi-Fi만으로 갈지, **유선 이더넷(=W5500 경로)**을 기본으로 둘지

클라우드 연동 범위: 모니터링만? 원격제어/스케줄/요금/빌링? OTA까지?

Related UCC & VAR: 

VAR 1(OCPP Module): https://maker.wiznet.io/matthew/resellers/full%2Dfeatured%2Docpp%2Dmodule%2Docpp/ 

VAR 2(EV Charger): https://maker.wiznet.io/ronpang/resellers/smartwall%2Dev%2Dcharger/