Last Update: Preliminary information, subject to change.
These are notes describing how to integrate Charging Essentials (CE) Smart Home energy monitoring switches, bypassing the CE control app.
NOT FOR PUBLICATION. CE Terms & Conditions prohibit reverse engineering and “unauthorized use of any and all Content”, protected or otherwise. Not an issue: see Tuya libs and also using Google Nest app.
The switches are WiFi devices that run in a LAN, and when the provisioning process is complete, the installed Smart Home app (Android or IoS) identifies the available devices, can turn each switch on or off, and also report the on-going energy use of each switch. The app is simple to use, and appears well written and robust.
The app, while useful, is intended for the end user. What we want to do is control the switch from nodes in our LAN, independently from the app.
There is no publicly available SDK information available from CE, so we have to see what information can be deduced using standard network tools.
What happens during the app provisioning process?
Using the device push-button to set the mode, switches broadcast as a LAN node, and the router assigns a DHCP address according to its setup. The switch then starts sending data packets every 2-3 seconds, The smart phone app is able to connect to the switch (i.e. pairing) , and the data packets are sent to the CE server (assumed a cloud service of some kind). When the app user turns a switch on or off, a command is sent to the switch.
In the app Settings panel, switch names can be edited as needed.
Finding and updating the IPv4 address using the MAC
The simplest and easiest way is to open the router management window. Because each switch is set as a DHCP node, its MAC address is listed. While not essential, for our project a switch MAC is used to reserve a specific IPv4 address. This ensures that the same IPv4 address will be assigned to a switch every time it is powered up. Addresses might be 192.168.0.176 and 192.168.0.185.
Project Requirements
We need to find out …
- the source and destination ports in use
- what protocol is being used (TCP/IP, UDP, JSON, other)
- are the data / control packets encrypted?
A local app has to
- identify the available switches on the LAN
- issue switch control on-off commands to a specific device
- ideally read the data packet and decode the energy consumption data
Protocol, and Source and Destination Ports
We used the Colasoft Capsa-Free network monitoring app to investigate the switches. As expected, TCP/IP is the network protocol, and the switches issue and respond via UDP (Universal Data Packet). Packets are 216 bytes, consisting of a 28 byte header, and 188 data bytes.
Switches source port is 49154, destination port is 6667.
This can be verified using the NetCat utility present is Raspbian and linux.
What do these ports mean? Capsa-Free shows us the UDP content coming from port 49154, so any code we write has to be able to read these packets. Since UDP does not specify a destination IPv4 (i.e it just broadcasts to the LAN), it’s presently assumed that the app has be able to open port 6667 to read the packet.
The converse applies well. When our app want to control the switch, we assume that the command packet is sent to, say, 192.168.8.176:6667.
More to add …
Copyright © 2025 PiXCL Automation Tech Notes, Canada. All Rights Reserved.