Closed HomeACcessoryKid closed 6 years ago
I think that to use MAC address instead accessory ID is better because you can identify easily the accessory in your network, and MAC address is fixed and never changes (accessory ID is random generated every time homekit config is erased from flash).
@RavenSystem: it would be better to use the MAC, I agree.
However, using MAC, I think it is not so easily picked up in server.c without including
Just tested this out on my esp32 project but it doesn't help. Every time I restart my ESP32 (power loss, or manual reset) its gets a new name. Homekit says "No response" and I have to add the Accessory again. In the log I see:
>>> HomeKit: Starting server
>>> HomeKit: Using existing accessory ID: AE:8D:02:BC:09:62
>>> HomeKit: Found admin pairing with BE27F8AE-7B7F-40D2-B111-9381143C0FEF, disabling pair setup
>>> HomeKit: Configuring mDNS
but in order to connect it again, I first need to call the homekit reset function.
Is this related to the fact that I use an esp32 (while most use ESP8266)?
can you reply with the log item similar to this one:
mDNS announcement: Name=Temperature Sensor-DFBB md=MyTemperatureSensorpv=1.0id=DF:BB:DA:05:1B:B8c#=1s#=1ff=0sf=1ci=9
If the DFBB part is missing then the fix is not yet applied…
Besides that, it never hurts to “delete your home” to reset all its memory of previous adventures… yes, it is a pity, but if things refuse to work, it might help…
Good luck, HacK
On 1 Sep 2018, at 11:47, Ruud Kamphuis notifications@github.com wrote:
Just tested this out on my esp32 project https://github.com/ruudk/esp32-homekit-contact-and-temperature-sensor but it doesn't help. Every time I restart my ESP32 (power loss, or manual reset) its gets a new name. Homekit says "No response" and I have to add the Accessory again. In the log I see:
HomeKit: Starting server HomeKit: Using existing accessory ID: AE:8D:02:BC:09:62 HomeKit: Found admin pairing with BE27F8AE-7B7F-40D2-B111-9381143C0FEF, disabling pair setup HomeKit: Configuring mDNS but in order to connect it again, I first need to call the homekit reset function.
Is this related to the fact that I use an esp32 (while most use ESP8266)?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/maximkulkin/esp-homekit/pull/60#issuecomment-417847047, or mute the thread https://github.com/notifications/unsubscribe-auth/AV0HQmJsm86WlXy-KpZ3h-f_z0sKWX-rks5uWleagaJpZM4WMZms.
I compiled it again with CONFIG_LOG_DEFAULT_LEVEL_VERBOSE=y
and CONFIG_HOMEKIT_DEBUG=y
but mDNS
only appears once, on this line:
>>> HomeKit: Configuring mDNS
I guess it doesn't print that on ESP32: https://github.com/maximkulkin/esp-homekit/blob/c2e67c468890b376343bf867309b31390af0dad9/src/port.c#L129-L134
Anyway, added a printf to this method:
void homekit_mdns_configure_init(const char *instance_name, int port) {
mdns_hostname_set(instance_name);
mdns_instance_name_set(instance_name);
printf("mDNS instance name %s", instance_name);
mdns_service_add(instance_name, "_hap", "_tcp", port, NULL, 0);
}
and it prints
mDNS instance name Contact Sensor-D1AD>>> homekit_run_server: Staring HTTP server
So that means I'm using the latest fix master release :) But it doesn't work good on ESP32.
The ESP32 does keep its instance name shown above, even after resetting and turning of power for a while. So that is good. The only issue is that Home.app doesn't recognise the accessory after that point. The ESP32 thinks its still registered but the only way to get it working again is to homekit_reset and re-add the accessory.
I already found the issue, my GPIO watcher was triggering my reset procedure 🤦♂️ Sorry for wasting your time.
This Pull Request aims to improve the bonjour name uniqueness by appending the 4 first digits of the accessoryID. Also, it tests the availability of an IP address before transmitting the mdns announcement and then repeats it after 1 and another 2 seconds. This is important for those systems that do not use the wifi-config since else the announcement is done with IP=0.0.0.0 and no visibility is achieved