The PL8331 datasheet contains information about the power metering UART and a temperature sensor.
I do not know what information exactly is needed, perhaps this helps.
The PL8331 is a SoC by itself, running some customized firmware from D-Link.
Thus, the protocol is most probably limited to what they needed for the cloud device, although the chip is apparently capable of providing a lot more information (maybe exact grid frequency, power factor etc.)
I also wonder what the max. sample rate would be, i.e. whether we could have an oscilloscope for the ac power line or something 
Indeed the temperature meter seems to be not a dedicated sensor, but just the built-in feature of the PL8331 chip, returning a measurement that should be in no way related to the actual room temperature, but more like the adapter's internal over-temp shut-off (to prevent the user from believing their device were defective when it switches off). Does the cloud service actually display an exact temperature value within the app?
The chip on the connection PCB is a PCA9306 two-channel level-shifter designed for i2c, so I also tried configuring the pins as i2c and run i2cdetect, but no result... the device would either reset (short-circuit on GPIO) or see a response on any address, depending on the sda / scl pin assignment...
I sniffed UART traffic in both directions (powering the whole thing with 12V, so that all 3 boards could be connected, allowing communication between QCA9531 and PL8331, and there is really just the UART protocol, as mentioned in the commit message:
:01M\n requested by the D-Link firmware,
$0S000\r (or something, alternating with something like $0S001\r),
but this was without 230V AC, so it probably contains less data than it should?
Have you tried flashing the factory image above?
mydlink will be overwritten, so I'm not sure whether you could set it back up with the dlink cloud again. Is there anything more displayed by the app than on/off status or power consumption in watts?
The w215 always felt a bit warm when it was in use. Since the housing is removed, I did some measuring. At certain places on one of the PCB's, the temperature measures about 55C (after flashing 72C) The flash IC seems to get the hottest.
The app indeed used to provide an exact temperature however now it shows 0C, the power meter does not work anymore as well (this was before flashing the firmware). I guess that I might have damaged something during the measurements of all pins.
Potential relevant information available in the app:
- on/off button and status
- power consumption (w)
- Thermal (C/F)
- device information: product name, firmware version, mac address
I have tested the firmware:
openwrt-ath79-tiny-dlink_dsp-w215-b1-squashfs-sysupgrade.bin: "Upgrade Failed !"
openwrt-ath79-tiny-dlink_dsp-w215-b1-squashfs-factory.bin: "Upgrade successfully!"
The device now no longer connects with the cloud, no problem. I can however still configure the wifi connection via the setup in the app.
This is curious, was this measurement done right at the beginning, when OpenWrt would boot for the first time? When JFFS2 is initialized, a lot of data is erased / written, within one minute or so after power on (until LED stops flashing), otherwise the flash should hardly see any traffic at all.
I agree the device gets quite warm though, maybe we could reduce the CPU clock or something (could probably be done using the pinmux driver), although OpenWrt usually does not change the values set by the bootloader, including clock settings.
While OpenWrt does not come with any software client to connect to the D-Link cloud, I wonder if flashing the device back to D-Link firmware would make it work with the cloud again? It should at least require re-adding to the account via the app, but I'm not sure whether any keys etc. might be required, that were stored in the mydlink partition. I could also not find the mydlink-ID in the mp partition, otherwise I would have used that as the Wifi PSK, since it would be long enough (some other DSP devices contain the mydlink ID in the MP partititon, e.g. DCH-G030 if i recall correctly).
It appears that the Qualcomm chip gets hot, not the flash IC. I had too much trust in the laser pointer of my aliexpress IR thermometer 
After leaving the device on for a while (without housing, with D-link firmware) I measured 72C, then I unplugged it. Perhaps the chip is damaged?
I flashed the D-link firmware back on the device however, no cloud connection is possible. I was able to add the device again, it is visible in the app however it says that the device is offline.
But no big deal, soon this will happen for all users.
The first time I checked an opened AVM FritzBox with a thermal camera, I thought it was broken too, but it seems to be normal that they run these chips on high temperature without any cooling radiator (planned obsolescence?). But for a switchable socket, this is quite a lot (considering this device is intended to actually save power ), and it probably won't need that much performance anyways.
I will look into reducing the clock setting for the CPU, hope this works by just modifying the dts (there are threads on the forum talking about bootloader modifications).
The mydlink partition could have been salvaged, but memory is quite tight already, this device would probably not survive for many years with new OpenWrt releases... and indeed people won't need it anymore in a few months 
Reduced the CPU Clock from 650 MHz to either 400 or 500 MHz.
The device seems to draw a little less power, but I can't see that much difference with the temperature.
With the old image (650 MHz), the chip is around 57°C.
Also fixed wifi mac address by removing the /lib/functions/k2t.sh include from 10_fix_wifi_mac (which was copied from ath79-generic, but does not exist in tiny, thus the script would exit before wifi mac could be corrected)
openwrt-ath79-tiny-dlink_dsp-w215-b1-squashfs-factory.bin (set to 400 MHz)
openwrt-ath79-tiny-dlink_dsp-w215-b1-squashfs-sysupgrade_400mhz.bin
openwrt-ath79-tiny-dlink_dsp-w215-b1-squashfs-sysupgrade_500mhz.bin
Seems as though the W110 could also be supported, though strictly under the tiny subtarget (seems like this works under the 5.15 kernel for e.g. the Nanostation M5 XM).
It seems the W110 is the non-metering (precedessor?) variant of W215, but only ever built with a US plug.
The case design somehow reminds me of another device, which is even more rare (and only available with US plug as well), I cannot remember the model name (although I own two of them, but can't find them right now 
). I think it was from the DAP-series, but has the same case design: It is a PoE Injector wireless bridge, e.g. a wall plug with an Ethernet port, that allows giving power + network for VoIP phones, surveillance cameras etc. with a single cable and wall plug. So cool, never saw anything like that. OpenWrt support is planned one day, when I find the time (and device)
1 Like
I happen to have one of those (B1 rev), and OpenWRT and the .bin posted here works flawlessly. I wonder where I can find the kmods for tun & other stuff ? Opkg points to a different kernel (5.15.xxx)....
Thanks, but 5.10.109 is not there:
root@OpenWrt:~# # Enable kmods repository
root@OpenWrt:~# . /etc/openwrt_release
root@OpenWrt:~# KERNEL="$(opkg list-installed kernel)"
root@OpenWrt:~# cat << EOF >> /etc/opkg/distfeeds.conf
> src/gz openwrt_kmods http://downloads.openwrt.org/\
> snapshots/targets/${DISTRIB_TARGET}/kmods/${KERNEL##* }
> EOF
root@OpenWrt:~# opkg update
Downloading https://downloads.openwrt.org/snapshots/targets/ath79/tiny/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading https://downloads.openwrt.org/snapshots/targets/ath79/tiny/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/base/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/luci/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/routing/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_telephony
Downloading https://downloads.openwrt.org/snapshots/packages/mips_24kc/telephony/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/snapshots/targets/ath79/tiny/kmods/5.10.109-1-735d9fb6afb6e5df3e374bcb7134dd6c/Packages.gz
*** Failed to download the package list from http://downloads.openwrt.org/snapshots/targets/ath79/tiny/kmods/5.10.109-1-735d9fb6afb6e5df3e374bcb7134dd6c/Packages.gz
Collected errors:
* opkg_download: Failed to download http://downloads.openwrt.org/snapshots/targets/ath79/tiny/kmods/5.10.109-1-735d9fb6afb6e5df3e374bcb7134dd6c/Packages.gz, wget returned 8.
Do I have to compile the whole thing for a 24Kb module?
For kmods, you do.
[OpenWrt Wiki] LED Configuration kmod-ledtrig-gpio would be particularly nice
Could it be as simple as adding into the DEFAULT_PACKAGES here?
openwrt/Makefile at master · s-2/openwrt · GitHub
Also has anyone managed to get a command to retrieve the temp or wattage values.. noob to this so not sure now to use the info the OEM firmware would transmit :01M\n on a regular basis
Happily still using my 8 plugs via ha-bridge on windows with alexa.. great work @s_2 !!
So this would basically mirror the state of a physical GPIO pin (e.g. the relay output to enable AC power), i.e. it could ensure consistency between the LED and the on/off status of the built-in power socket? That sounds useful, however I can not see from the documentation how this needs to be configured.
Regarding power metering, I had mostly used the device as a naked PCB on my desk during development, connected to a 12V supply, with wires soldered to it for uart etc., so I could not really attach a "real" 230V AC device and measure the consumption, but the command :01M, followed by newline, is what the OEM firmware would transmit via serial to the power metering IC. You could connect to /dev/ttyS0 via screen etc., and see what comes back after transmitting this sequence, depending on the power of the device attached.
@s_2 thanks for taking the time to respond.. All this is kind of new to me.. But yep the device in it's native state the power led is green when /sys/class/gpio/gpio:ac_output_enable/value == 1 and off when /sys/class/gpio/gpio:ac_output_enable/value == 0
Also in it's native state pressing the power button (agpio2??) toggles the gpio:ac_output_enable value.. which I think can be done by adding buttons and actions into the config?
I'd been reading [OpenWrt Wiki] Adding new device support and [OpenWrt Wiki] Attach functions to a push button
but hadn't go much further... I'm on windows too so would need to do some running to get up to speed in order to try and build something myself
The other thing I noticed.. that via LuCui there is /cgi-bin/luci/admin/system/startup a localstartup that could be leveraged rather than needing to actually build?
Also had another thought re the power meter.. as I'm emulating a philips hue light in ha-bridge to have alexa support.. maybe the brightness setting could be somehow repurposed to access the watts? 
Hi, does anyone have a copy of the latest official software for b1 version?
On the German ftp, they put them in the archive folder for whatever reason:
// and Discourse just let me know the link was already posted, it is in the very first post of this thread 
I was also notified of the system clock being wrong due the CPU clock speed changes, i.e. when setting the time via date and retrieving it later, it would be way too slow. So we should stick with 650MHz until there is a CPU governor available in the ath79 target, which most probably will never happen.
Regarding button configs, honestly I have never used this, but yes, there should be some daemon etc. running on the device that would take care of all this, and maybe offer MQTT or something to include this into a home automation system, but by default, there is nothing like that like in OpenWrt working out of the box.
I'm not sure how the brightness display works in ha-bridge, but if it could actually read a brightness level (not just set one and display that), there should be a way to map the watts to a brightness gauge etc.
1 Like
@mistyn8 there seems to be a really old version and for the A1 hardware
@s_2 somehow the ftp does not work anymore (at least for me)
I did manage to find V2.20 which seems to work fine with Domoticz.
Checking this topic for future updates. Hope that Openwrt will have power usage meter support and fancy gui for power management in the future. Good work guys!