Closed 8191 closed 1 year ago
Hi, are you getting any specific issue with the present code? The UUID for Fakegato service is already set at line 146 (and line 132 for Plarform API). I suppose the line you modified is a leftover from some code refactoring.
Hi,
the UUID set in line 132 is actually the UUID of the class FakeGatoHistoryService
which is not exported. The only exported class FakeGatoHistory
never receives an UUID.
Yes, I had a specific error fixed with that: I'm trying to integrate your service into the homebridge-shelly plugin, which uses following pattern to access services:
get service() {
return this.platformAccessory.getService(FakeGatoHistoryService)
}
As the getService
method of homebridge tries to access the static UUID of the service, the service was never returned, as the exported class of your module did not have any UUID assigned.
Also to remove the service from an accessory the UUID is quite handy:
for (const s of this.platformAccessory.services) {
if (s.UUID == FakeGatoHistoryService.UUID) {
this.platformAccessory.removeService(s)
}
}
As I said, UUID is also already set for FakegateHistory at line 146. Then it is set for FakegatoHistoryService at line 132 if needed (see function registerEvents). This section has not been changed for a long time and a long time, and no issue has been reported so far, so it’s very strange.
Did you check in debug if you are entering these two lines, depending on whether your accessory is platform or accessory type? Which version of homebridge are you using? Could you share your code? @NorthernMan54 could you have a look at this?
I've just checked in debug with both a platform and an accessory type plugin, and in both cases UUID for FakegatoHistory service is set by line 146
super(accessory.displayName + " History", FakeGatoHistoryService.UUID);
And it has to be, otherwise Eve would not recognize the service. So I can only suppose that for some reasons that line is skipped or not working as expected in your setup. I'm on homebridge 1.5.3, but I suppose many other users are already on 1.6.0. Please debug and check around that line.
@8191 I just checked my running implementation and the history service is created correctly
Am thinking this line might be a typo from a few years ago
To get the internal representation of the service from Homebridge you can run this against your environment
https://github.com/NorthernMan54/homebridge-alexa#homebridge-accessory-dump
Thanks for having a look into this, @simont77 @NorthernMan54! In the meanwhile I found out, that the problem is maybe something else than the missing UUID: the HistoryService cannot be correctly deserialized when starting homebridge. It's being deserialized as a Service
instead of as a HistoryService
. I believe that caused my problem, but I've fixed that in a different way...
The exported service FakeGatoHistory has no UUID assigned.