Yes, Iâm still connected:
[20200615 02:08:26] [D] method_local_broadcast_msg(), {âmethodâ: âlocal.statusâ, âparamsâ: âcloud_connectedâ}
I managed to capture the motion events and upload requests of the files via MQTT which allows to have the status etc. available on an MQTT Server.
Motion detection:
{âidâ:5174349,âmethodâ:âevent.motion1â,âparamsâ:[â2020/06/17/987654321/5309307225_055003386.mp4â,âxxxxxxxxâ,â2020/06/17/1903657091/5309307225_055002985.jpegâ,âxxxxxxxxâ,"",â1â]}
The status can actively be requested via MQTT message:
{âfromâ:â4â,âidâ:22,âmethodâ:âget_camera_propâ,âparamsâ:[âCAM-IDâ,1]}
Response:
{âidâ:22,âresultâ:[{âmacâ:âAABBCCDDEEFFGGâ,ânameâ:âCAM1â,âwifiâ:1,âbatteryâ:40,âbattery_statusâ:1,âpirâ:0,âversionâ:â10030â,âhardverâ:â110100â,âpowerâ:0,ânightâ:0,âeventâ:âmotionâ}]}
For the JPG and MP4 files: I added a second http instance which allows direct access to files stored on the SDCARD.
I still need to figure out the relationship between the events and the filenames as the stored files are following an other convention as the uploaded files and I need to find a way to match both and I need to identify the different cameras
The changes so far are simple:
1.) I configured mosquitto to act as a MQTT bridge and forward the messages to my local MQTT server
2.) I added a second uhttpd instance on port 8881 for accessing the media files
3.) I enabled additional miio_client logging to sdcard - the binary is responsible for transforming the camera requests to MQTT
As for test_hub: I could not find any application which calls this binary. Although test-hub.sh etc. is checking for relesase/debug, it seems that itâs never called which is diametral to what you reported about user lockouts. As a result, I still have telnet access.
To workaround a possible lockout, Iâm going to enable cgi-bin for the new media instance of uhttpd, allowing to reactivate telnetd whenever necessary