By my standards this is a bit of a random one. But this was very much on brand in terms of “learning new things”. Prior to this mini-adventure, I’d had only one prior experience in poking around with hardware, at least to this degree. My last bit of hardware tinkering was to get Tasmota running on a SONOFF RF Bridge R2, it was a bit more involved than this as I needed to cut traces and solder bits… and I cannot even remember why I did all this in the end. I think it was so that I could send RF signals via Home Assistant to my “dumb” Gazco fireplace, making it somewhat smart. Either way, that was quite fun – wires everywhere, soldering iron in hand, and a bit of a playtime project. Whatever it did, or I did, worked, and I can now instruct Siri to turn the Fire on and off, should I wish.

But anyway, this post is nothing more than a documentation dump related to a very niche requirement.

I purchased a “presumably used” Birdfy Nest Duo as my little Mr has his mothers passion for nature. He’s paid great attention to this years Blue Tit’s checking out the “dumb bird box” and has a general interest in nature – whilst not my passion, I’m not one to stand in his or anyones way AND I figured I could kill two birds (figuratively speaking!) and replace the dumb bird box with a smart one. I get my tech kicks, and little Mr and his mother can enjoy watching the birds come and go and maybe even nest.

When the Birdfy Nest Duo arrived, I simply hooked it up to USB and attempted to configure the app. I hit a stumbling block. The App requires you to scan a QR code which contains the Device ID, so that the App and camera’s can talk – there is also a manual entry input in the app, should the QR not work, but this requires the Device ID to be visible. The problem? This unit I had received had no QR code, or identifying factors at all – Great.

I hopped onto Birdfy support chat and the first thing they need/want from you is the Device ID. Can’t help with that, sorry. I explain there’s simply no sticker or identifying features, they explain they cannot help. They simply state. Without a QR or Device ID sticker on the unit, there is no way to identify the unit – which in short renders the unit absolutely useless to a mere mortal, an expensive brick if you like. This is not what I would class as a suitable answer to a problem that can quite easily occur naturally, through no fault of the owner, over time. (By constant weathering of the unit for example! This is an outdoor device! The QR is on a sticker, on the camera, which in the UK means it’s probably going to get rained on 8 out of 7 days a week! A bit of rain and a gust of wind and theoretically that sticker could easily disappear.)

Anyway, not being happy with that answer and being a techie, and knowing tech, I assumed there MUST be a way to get this up and running, or at least get some kind of identifying information to allow me to proceed. So I began poking. I quickly established there’s an SD slot and wondered if it simply needed a firmware update. Lets try it! Or, let’s not. Birdfy don’t publish the firmware files and every attempt to pry the files from support resulted in being stonewalled without a Device ID.

Next stop, out with the screwdrivers. Let’s have a quick peek and see what we’re working with. I managed to quickly remove the cameras and processing unit, hoping that in doing so, I might actually find the QR sticker had been stuck to the wrong side or something. It had not.

So I had the two camera’s and processing unit in my hands. The camera’s had nothing much in the way of screws, nor did they suggest there was much inside them worth exploring. So I turned my attention to the processing unit. This appeared to be plastic welded shut, but upon inspection, I realised it was not, and that it simply had a rubber gasket tightly fitted to prevent any ingress of moisture. Underneath there were four rubber feet, which almost always is a disguise for screws, so I whipped out the rubber feet, and sure enough, there were screws.

Removing the four screws gave access to the brains. The brains didn’t immediately reveal anything obvious, at least not to me. The reality is, after removing the screws I’m a little lost as to what I’m looking at.

The front of the PCB contained some identifying features. An Ingenic T40 chip, MÁT40N-20A3T-03-0 VER. E printed on the board and a sticker with a QR code and what appears to be the back end of a MAC Address. Scanning this QR was futile. Given it’s located near the WiFi Antenna, and has what appears to be a MAC address, I figured that was likely the WiFi controller, and not what I was after. I did however triple check that the 6 readable digits was not the Device ID – it was not.

At this point I’d been researching potential avenues. I found that the Birdfy was likely a Netvue devices, so had a trawl on eBay for Birdfy/Netvue devices to see if I could at least establish what a Device ID might look like character wise. It turns out, 16 digit numerical string would appear to be the answer. Nothing obvious on the front. So what about the back?

I removed the PCB from the chassis and flipped it over. This meant disconnecting the Battery and WiFi antenna. I could have probably kept both connected and just pried underneath, but it wasn’t worth it – I didn’t want to break anything.

Interestingly however, upon flipping the PCB over there was a sole sticker with a 16 digit reference. 8 characters were printed horizontally, 8 vertically. When trying the vertical 8 followed by the horizontal 8, I got an error in the App – Invalid Device ID. However, when trying the horizontal 8 followed by the vertical 8, I got a different error.

By this point I was starting to lean towards hardware failure (either by faulty software/firmware), device failure or potentially a (purposely) blocked device. These however, were just assumptions.

After some more googling, I’d found this Reddit thread in which the original poster had been able to extract some information from his Netvue/Birdfy by way of UART – in this particular example on Reddit, the user was able to pull back the elusive Device ID which is what I was on the hunt for. As mentioned at the top, I’d originally poked around with some UART bits on a SONOFF unit, but this was a while ago, and being honest, I’d forgotten how I managed it. Anyway, being clueless didn’t stop me. Previously I’d used an Arduino as a middle man to read the UART from SONOFF, finding that all a bit too convoluted, at the time I’d ordered a USB to TTL UART converter which until now had gone unused.

I found some rough instructions on defining the COM settings (for reference; 115200 bps baudrate, 8 bits, no parity, 1 stopbit, no flow control) and had a quick refresher in PuTTY term (but ended up using TeraTerm) and had what I believed to be sufficient information to take the “poking around” to level 2.

With the equipment in hand, and the PCB out of the housing. The next part was to identify what goes where when trying and readout the UART console. This process was made all the more difficult by not exactly having the most secure (secure as in stable, as in being able to lock down a stable connection) setup. By this, I mean that in order to readout the UART console, I had to hold the cables on the UART pins and drive the console one handed on my laptop. A slight knock and I’d fall off the pins and lose console. I figured I only needed a quick blast to get the Device ID. How wrong was I!

Anyway, after much trial and error, and by this I mean many hours spent identifying the actual UART pins, it was with a short blast of a steady hand, that I managed to get a full read out.

Two things jumped out. There’s no Device ID jumping out at me, and secondly, the device is stuck in a boot loop… Hmmmm…. Is this the reason it’s not working?

Actually three things. No authentication required, at all (well, not at this point). Nice.

Ver:20220122-T40N
[    0.104585] i2c i2c-1: i2c_ingenic_irq 446, I2C transfer error, ABORT interrupt
[    0.104617] i2c i2c-1: --I2C txabrt:
[    0.185657] ingenic,watchdog 10002000.watchdog: Failed to get mfd cell
[    0.238943] mmc0: Got command interrupt 0x00010001 even though no command operation was in progress.
Setting up swapspace version 1, size = 16773120 bytes
UUID=8c3bbe85-3305-4815-8417-c1e7c926bed1
[envtool] 1613 I serviced/extlib/path.c(191):[envtool] - mkdir '/var/run/nvc' success
sdcard upgrade start

netvue login: [loaderd] 1685 I serviced/extlib/path.c(177):[loaderd] - mkdir '/tmp/nvc' success
[loaderd] 1685 I serviced/extlib/path.c(177):[loaderd] - mkdir '/tmp/nvc/s3' success
[loaderd] 1685 I serviced/extlib/path.c(177):[loaderd] - mkdir '/tmp/nvc/s3/log' success
[loaderd] 1686 I serviced/emlib/signal0.c(62):[loader] - sigaction success
[loaderd] 1693 I serviced/loader/loaderd.c(186):[loader] - logger_start
[loaderd] 1694 I serviced/loader/loaderd.c(187):[loader] - watchdog_start
[loaderd] 1694 I serviced/loader/watchdog/watchdog.c(9):[loader] - watchdog_start
[loaderd] 1694 I serviced/loader/watchdog/hardware.c(140):[loader] - watchdog_hardware_start
[loaderd] 1694 I serviced/loader/watchdog/server.c(268):[loader] - watchdog_server_start
[loaderd] 1695 I serviced/loader/watchdog/server.c(272):[loader] - watchdog server start success
[loaderd] 1695 I serviced/loader/watchdog/mmc.c(39):[loader] - watchdog_mmc_start
[loaderd] 1696 I serviced/loader/loaderd.c(189):[loader] - main_start
[loaderd] 1696 I serviced/loader/loaderd.c(190):[loader] - upgrade_start
[loaderd] 1696 E serviced/extlib/utils.c(292):[loader] - read /mnt/mtd/netvue/firmware/config/v4/main.config error: No such file or directory
[loaderd] 1696 W serviced/loader/upgrade/upgrade.c(52):[loader] - use default web endpoint:https://localweb.nvts.co
[loaderd] 1697 I serviced/loader/loaderd.c(191):[loader] - upgrade_ca_srv_start
[loaderd] 1697 I serviced/loader/watchdog/hardware.c(73):[hardware] - WDIOC_SETTIMEOUT 120 success
[loaderd] 1698 I serviced/loader/upgrade/upgrade.c(178):[upgrade] - upgrade start at 1698
[loaderd] 1702 I serviced/loader/main/main.c(68):[main] - main 141 start
[loaderd] 1733 E serviced/loader/upgrade_ca/utils.c(138):[upgrade_ca] - cur time 1733 < 1748989574305 maybe not sync
[loaderd] 1766 E serviced/loader/upgrade/http.c(177):[upgrade_report] - curl_easy_perform error: Couldn't resolve host name
[loaderd] 1767 I serviced/loader/upgrade/upgrade.c(196):[upgrade_report] - report upgrade status: 6 failed
[main] 1718098801002 E serviced/extlib/io.c(192):[main] - stat /mnt/mtd/netvue/firmware/config/v4/main.config error: No such file or directory
[loaderd] 1718098801004 I serviced/loader/watchdog/server.c(87):[watchdog_server] - accept #9
[    0.839528] i2c i2c-1: i2c_ingenic_irq 446, I2C transfer error, ABORT interrupt
[    0.847355] i2c i2c-1: --I2C txabrt:
/root/application/src/nv/adapter/av/plat/ingenic/t40/nv_sys_av.c(95-(nil)): nv_sys_vi_sensor_init assert(call IMP_ISP_EnableSensor failed. -9) error!!
[loaderd] 1718098801300 I serviced/loader/watchdog/server.c(144):[watchdog_server] - #9 eof
[loaderd] 1718098801300 I serviced/loader/watchdog/server.c(156):[watchdog_server] - #9 close
[loaderd] 1718098801311 I serviced/loader/main/main.c(97):[main] - main 141 exit with signal 1 code 0
[loaderd] 1718098801311 I serviced/loader/main/main.c(110):[main] - main loop exit
[loaderd] 1718098802901 E serviced/loader/upgrade/http.c(177):[upgrade_report] - curl_easy_perform error: Couldn't resolve host name
[loaderd] 1718098802901 I serviced/loader/upgrade/upgrade.c(196):[upgrade_report] - report upgrade status: 6 failed
[    3.044056] watchdog watchdog0: watchdog did not stop!
umount: devtmpfs busy - remounted read-only
Sent SIGKILL to all processesid
Requesting system reboot
[    5.460857] reboot: Restarting system

Ver:20220122-T40N
[    0.103361] i2c i2c-1: i2c_ingenic_irq 446, I2C transfer error, ABORT interrupt
[    0.103394] i2c i2c-1: --I2C txabrt:
[    0.184508] ingenic,watchdog 10002000.watchdog: Failed to get mfd cell
[    0.237760] mmc0: Got command interrupt 0x00010000 even though no command operation was in progress.
[    0.247179] mmc0: Got command interrupt 0x00000001 even though no command operation was in progress.
Setting up swapspace version 1, size = 16773120 bytes
UUID=300855d7-dd96-41e6-92d5-c353d47b1f19
[envtool] 1619 I serviced/extlib/path.c(191):[envtool] - mkdir '/var/run/nvc' success
sdcard upgrade start

.... and so on

I got hooked on the error around Firmware and Mount, and config file not being found. As such, I leaned heavily towards this being a firmware issue. I pushed hard to try and get the Birdfy team to send me the latest firmware, but got stonewalled without the Device ID.

So knowing I had a way in to the console, I continued to have some fun… this was all whilst having to battle the ongoing “launcherd” spam received constantly throughout Terminal connection.

netvue login:
netvue login:
netvue login: [loaderd] 1718098812961 E serviced/loader/upgrade/http.c(177):[upgrade_report] - curl_easy_perform error: Couldn't resolve host name
[loaderd] 1718098812961 I serviced/loader/upgrade/upgrade.c(196):[upgrade_report] - report upgrade status: 6 failed

netvue login:
netvue login:
netvue login:
netvue login: roo[loaderd] 1718098814974 E serviced/loader/upgrade/http.c(177):[upgrade_report] - curl_easy_perform error: Couldn't resolve host name
[loaderd] 1718098814974 I serviced/loader/upgrade/upgrade.c(196):[upgrade_report] - report upgrade status: 6 failed
t
Jun 11 09:40:15 login[118]: root login on 'console'
[root@netvue:~]# [loaderd] 1718098815864 E serviced/loader/upgrade_ca/utils.c(138):[upgrade_ca] - cur time 1718098815864 < 1748989574305 maybe not sync
[loaderd] 1718098816987 E serviced/loader/upgrade/http.c(177):[upgrade_report] - curl_easy_perform error: Couldn't resolve host name
[loaderd] 1718098816987 I serviced/loader/upgrade/upgrade.c(196):[upgrade_report] - report upgrade status: 6 failed

[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]# [loaderd] 1718098819000 E serviced/loader/upgrade/http.c(177):[upgrade_report] - curl_easy_perform error: Couldn't resolve host name
[loaderd] 1718098819001 I serviced/loader/upgrade/upgrade.c(196):[upgrade_report] - report upgrade status: 6 failed

[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]#
[root@netvue:~]# [loaderd] 1718098820865 E serviced/loader/upgrade_ca/utils.c(138):[upgrade_ca] - cur time 1718098820865 < 1748989574305 maybe not sync
[loaderd] 1718098821014 E serviced/loader/upgrade/http.c(177):[upgrade_report] - curl_easy_perform error: Couldn't resolve host name
[loaderd] 1718098821014 I serviced/loader/upgrade/upgrade.c(196):[upgrade_report] - report upgrade status: 6 failed
ls
bin      etc      linuxrc  proc     run      sys      tmp      var
dev      lib      mnt      root     sbin     system   usr
[root@netvue:~]# [loaderd] 1718098823027 E serviced/loader/upgrade/http.c(177):[upgrade_report] - curl_easy_perform error: Couldn't resolve host name
[loaderd] 1718098823027 I serviced/loader/upgrade/upgrade.c(196):[upgrade_report] - report upgrade status: 6 failed

Eventually, I was able to battle through to /mnt/mtd/netvue/firmware/config and open up wifi_config.txt, which revealed an SSID and PSK in plain text.

So I created an SSID with the same PSK at home, and the device connected to the internet. Allowing it to somewhat heal itself. Sufficiently enough to stop the “launcherd” spam anyway!

Snooping around /mnt/mtd/netvue/firmware/config I was able to pull the Device ID and in doing so, it matched the sticker on the rear… Interesting.

Confirming the Device ID, I reached out to support, giving them the correct and confirmed Device ID, only to be told that the device had been banned/blacklisted having previously being replaced. Instant game over in terms of resurrecting a Birdfy Nest Duo.

However, much UART fun was had, no joy in fixing the damned product – but lessons were learned. Mostly, Birdfy/Netvue have not a care in the world for eWaste, simply shipping out replacement products and bricking old ones. This to me shows how little value the actual tech carries, i.e. it’s cheaper to write them off than have them returned for repair.

Other lessons learned. UART is interesting. A follow on lesson learned, ensure you have suitable connectors for probing UART if needing to do this frequently. Holding the pins with one hand and driving a linux console being spammed by logs with the other, was not pleasant.

Finally, I’m wondering if different firmware like openIPC or thingino might be a route forward to salvaging Birdfy/Netvue bricks? I’ll never know, as I returned the defective item… but could be of interest to someone else in future!