0.4.1

[alienatedsec]

Breaking changes !!!

• There is a new baseline 0.4.1, so you need to prepare your SD card for it - follow Specifics of the yi-hack-v5 firmware and flashing #267 and this guidance Pre-Release Versions #248
• The camera web page is no longer under port 8080 but back to default port 80 - access your camera web page using its IP only. Those with proxy environments or Home Assistant integrations must amend their settings.
• The new baseline is needed to fix OTA upgrade OTA FW upgrade shows no value for "Available:" #326 - cameras on earlier versions cannot upgrade from the WebUi as there is an additional baseline check - it refers to 0.4.1 for the latest release - 23a96a5 - copy the release file onto your SD card and change its name as per the guidance in Pre-Release Versions #248
• Future non-baseline upgrades will not require a FAT32 SD card preparation

What's Changed (Generated by GitHub, high-level)

• @roleoroleo testing merge for pre-release by @alienatedsec in Roleo testing merge for pre-release #289
• Merging tested commits by @alienatedsec in Merging tested commits #299
• Merging onto pre-release by @alienatedsec in Merging onto pre-release #330
• [~] Onvif fixes by @alienatedsec in [~] Onvif fixes #331
• fix: WARNING in HA => MQTT entity name starts with the device name in… by @Minims in fix: WARNING in HA => MQTT entity name starts with the device name in… #327
• fix: mqtt disconnecting immediately after boot by @fidesachates in fix: mqtt disconnecting immediately after boot #328
• Pre release 0.4.1x by @alienatedsec in Pre release 0.4.1x #341
• Improve MQTT by @Minims in Improve MQTT #349
• Pre release 0.4.1x merge to master by @alienatedsec in Pre release 0.4.1x merge to master #355

What's Changed (in detail)

Sorry for the below mess - I will try to be consistent with the next releases

• Restore feature to edit config files
• Add a flag to decrease binary size
• Remove old patch
• Decrease RTP packet length
• Improve sync/async read
• Update gitignore
• New features: disable, force low and already running
• Remove unused settings from config files
• Add options to disable snapshot and force low res
• Remove unused mqtt options
• Fix and improve h264grabber
• Fix system.conf parameters
• Remove ai_human_detection and restore baby_crying
• Wi-Fi Recovery Partition - Instructions in progress
• Change size of FIFO queues
• Restore audio stream ch0_2.h264
• Add native API to take low-res snapshot
• Remove option: watermark for onvif snapshot
• Change label for "Force low res snapshot"
• Improve RTSP server
• Minor fixes
• Remove unused options when empty password
• Add mqttv4 to watchdog
• Add "if supported" in camera settings page
• Add support for native time osd
• [Change] launch.sh optimised to kill gently
• [Change] Tuning launch.sh
• [New] Compile specific module - thanks @thelittlefireman
• wpa_supplicant upgrade to v2.10 - this was an attempt to prevent boot loop issues experienced with certain Wi-Fi configurations (e.g., multiple APs with the same SSID) or any modern Wi-Fi networks - for example, a mixed mode WPA/WPA2 is subject to be removed in the future wpa_supplicant releases
• Initial support for WPA3-Personal - Simultaneous Authentication of Equals (SAE)
• Support to encrypt your Wi-Fi password with wpa_passphrase
• Fixing cloudAPI workflow for CN-based cameras
• Removed duplicate configs
• Merging @roleoroleo 's work onto pre-release in Merging onto pre-release #330 and [~] Onvif fixes #331 - too many changes to list them all here
• fix: WARNING in HA => MQTT entity name starts with the device name in… by @Minims in fix: WARNING in HA => MQTT entity name starts with the device name in… #327
• fix: mqtt disconnecting immediately after boot by @fidesachates in fix: mqtt disconnecting immediately after boot #328
• Fix for [0.4.1.e] - Yi Home 27US - Unable to Flash #334 - reduced the image size by compressing multiple large files in the home partition
• Fix for [0.4.1e] No timestamp watermark on stream #336 - added missing config thanks @lebestnoob
• Fix for yi_home and yi_dome - the wpa_supplicant upgrade in the baseline image was prevented by the YI upgrade of an older file
• Recovered lost system.sh upgrades and other functions
• Cleared the libs folder on the home partition - attempt to fix Rootfs corruption after a few months - bootloop #312 and Boot Loop Investigation #291
• The Busybox was upgraded to 1.36.1 and its size was reduced to address Rootfs corruption after a few months - bootloop #312
• Moved some tools from rootfs to /tmp/sd/yi-hack-v5/.../[s]bin folders using busybox_tools submodule - again to address Rootfs corruption after a few months - bootloop #312
• Fixed Curl SSL crypto library
• Fixed symlink to VI Missing a link to the binary on the sdcard ? #346
• Fixed the MQTT issue MQTT status changes many times per second (offline/online) when RTSP server is activated (0.4.1.e) #333
• Fixed no watermark in streams [0.4.1e] No timestamp watermark on stream #336 - thanks @Minims
• Amended config reading - seems to work quicker - thanks @Minims
• Added file versioning - so that we can track changes without upgrading the baseline
• Improve MQTT by @Minims in Improve MQTT #349 - please test if working as intended
• Fixed WiFi scan page
• Improved the wpa_supplicant upgrade logic
• Reduced busybox_tools size on the SD

New Contributors

• @Minims made their first contribution in fix: WARNING in HA => MQTT entity name starts with the device name in… #327
• @fidesachates made their first contribution in fix: mqtt disconnecting immediately after boot #328
• @roleoroleo made so many contributions - thanks for the additional effort

Full Changelog: 0.4.0...0.4.1

---

This discussion was created from the release 0.4.1.

[reef-actor]

This looks great, thanks for all your efforts. To clarify, is it necessary to upgrade by FAT32 sd-card method if I am on pre-release 0.4.1e already?

[alienatedsec]

Thanks @reef-actor
yes, please upgrade as per the release notes - the only reason is that version 0.4.1e is too far behind 0.4.1j 0.4.1e...0.4.1j which this final version is based on.

[g1za]

Following the port change, what is the new location for recorded video files?
I have an automation that used to send the videos via Telegram and I updated the code to reflect the new port but this is the MQTT message I get, which seems to point to the wrong location, as files is empty

Message 15 received on yicam/motion_files at 23:06:
{
"start":"2024-02-26T23:04:04+01:00",
"end":"2024-02-26T23:05:11+01:00",
"files":[ ]
}
QoS: 0 - Retain: false

I updated the url in my automation from

action:
    - repeat:
        for_each: '{{ (trigger.payload_json.files) | sort() }}'
        sequence:
          - service: telegram_bot.send_video
            data:
              target: !secret telegram_chat_id
              username: !secret yi_camera_user
              password: !secret yi_camera_pwd
              url: "http://192.168.188.7:8080/record/{{ repeat.item }}"

to

action:
    - repeat:
        for_each: '{{ (trigger.payload_json.files) | sort() }}'
        sequence:
          - service: telegram_bot.send_video
            data:
              target: !secret telegram_chat_id
              username: !secret yi_camera_user
              password: !secret yi_camera_pwd
              url: "http://192.168.188.7/record/{{ repeat.item }}"

which seems correct; but given the MQTT message maybe the files are not being retrieved at all? If needed I can open a bug.
Thanks!

EDIT:
Also this one seems to be empty:

Message 17 received on yicam/motion_detection_image at 23:16:

QoS: 1 - Retain: false

[g1za]

I reinstalled the hack, formatted the SD from the app. At that point the yi-hack folder was missing and I was unable to access the web interface. I copied that folder again but the MQTT message on recorded events is still the same (empty) while I can see the recorded video on the events tab. Should I open a ticket?

{
"start":"2024-02-27T00:30:32+01:00",
"end":"2024-02-27T00:31:46+01:00",
"files":[ ]
}

QoS: 0 - Retain: false ```

[alienatedsec]

Apologies @g1za but the new Busybox must have "broken" a certain way of working. Its not a bug as such, and I guess the way you used it before had some security implications.

[g1za]

I see but it seems strange to me this had security implications. In the end it was just listing the name of the files. Are we sure it is pointing to the new location (port 80, instead of 8080) to retrive filenames? Would that explain why the list is empty?

[alienatedsec]

I will check as soon as I can. @g1za

[roleoroleo]

It could be a timezone issue.
I've had a similar problem in the past.
I will check it.