simont77 / fakegato-history

Module to emulate Elgato Eve history
MIT License
167 stars 15 forks source link

Name of _persist.json file #46

Closed ebaauw closed 6 years ago

ebaauw commented 6 years ago

I'm having some concerns on the fakegato-storage functionality, particularly the filenames used:

Arguably, not every-one might share my concerns. Both issues could be addressed by adding an additional filename option to the FakeGatoHistory, so each plugin can control their own behaviour.

NorthernMan54 commented 6 years ago

Erik,

Do you know if we have access to the serial number as part of the object? I think in the platform V2 API we should be able to access the information service, but in the accessory or V1 I don’t think it is accessible.

For the hostname, that was for me where I have a test environment, plus production and I overwrote the data numerous times.

I’m okay with your thoughts, and enhancements.

On Feb 28, 2018, at 6:03 PM, Erik Baauw notifications@github.com wrote:

I'm having some concerns on the fakegato-storage functionality, particularly the filenames used:

When using {storage: 'fs'} as option to FakeGatoHistory, it doesn't seem to make sense to use the hostname in the filename. Multiple instances of homebridge need to be run from a different user directory anyway, ensuring each instance logs to a different directory; The accessory displayName is not guaranteed to be unique and might actually change over time. Instead, I'd rather see the accessory serial number in the filename. Still I would like to base the name of the history service on the accessory display name. Arguably, not every-one might share my concerns. Both issues could be addressed by adding an additional filename option to the FakeGatoHistory, so each plugin can control their own behaviour.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/simont77/fakegato-history/issues/46, or mute the thread https://github.com/notifications/unsubscribe-auth/AS5CmCf-x7fdekg4FhEpbRXY9AjFDk2Iks5tZdtXgaJpZM4SXfv4.

ebaauw commented 6 years ago

Thanks, Sean.

Do you know if we have access to the serial number as part of the object?

That would indeed be up to the plugin. We could use a convention that it should be in accessory.serialNumber, just like using accessory.displayName, but I think it's safer to just pass it as parameter.

I'm actually now storing the persist files in ~/.homebridge/accessories (or accessories in the user path). Seems to make sense to me, as homebridge stores the persisted accessories there as well, for V2 platform plugins.

NorthernMan54 commented 6 years ago

Sounds good.

PS For majority of my devices the display name is the serial number, ( I have a dozen nodemcu based temperature sensors and I just used the hostname “node-aabbccddeeff” as the display name ). So when I look at my googledrive, they are serial numbers.

On Feb 28, 2018, at 7:10 PM, Erik Baauw notifications@github.com wrote:

Thanks, Sean.

Do you know if we have access to the serial number as part of the object?

That would indeed be up to the plugin. We could use a convention that it should be in accessory.serialNumber, just like using accessory.displayName, but I think it's safer to just pass it as parameter.

I'm actually now storing the persist files in ~/.homebridge/accessories (or accessories in the user path). Seems to make sense to me, as homebridge stores the persisted accessories there as well, for V2 platform plugins.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/simont77/fakegato-history/issues/46#issuecomment-369428438, or mute the thread https://github.com/notifications/unsubscribe-auth/AS5CmNSnG-IPzPhs80EvTknYfoR0_Eivks5tZzxigaJpZM4SXfv4.