uhppoted / uhppoted-app-home-assistant

UHPPOTE controller integration with Home Assistant
MIT License
8 stars 1 forks source link

Not getting unlocked status event #1

Closed m0vse closed 7 months ago

m0vse commented 8 months ago

Hi.

Well done for creating this, I realise some features are a bit rough, but I have been able to configure it for our building which has 3 floors with a controller on each floor.

With all of the doors, I am able to unlock them using uhppoted.door.{door}.unlock and the uhppoted.door.{door}.lock status shows unlocked until the next poll. However the uhppoted.door.{door}.unlocked.event appears to never fire for any door and the status is always shown as Unknown. Any ideas?

All of my controllers are V6.62.51215 which I realise is pretty old...

One other thing that would be good to know, is there anyway to import the existing swipe records from a controller?

Good work so far though.

Phil

m0vse commented 8 months ago

To update this, after a bit more research, it appears that 'some' doors are working and generating the unlocked events. Of our 9 doors, 3 seem to work. There seems to be no pattern though (different numbers doors on different controllers?)

uhppoted commented 8 months ago

Oh dear .. I guess this means I'm going to have to remove the bit in the README which says "... probably not suitable for office buildings" :-).

Hmm, v6.62.51215 firmware should be ok - it's the earliest version that is known to work, although it does have some oddities that were fixed in later versions. But I've just checked and the code is in place to handle those.

Oh .. oops! Best guess is that the controllers are probably not configured to send events to the Home Assistant machine and uhppoted-app-home-assistant doesn't configure them automatically either. I need to think about how best to do that - but if you want to configure them manually in the interim, the easiest is probably the CLI set-listener command:

set-listener <controller> <address:port>

e.g. uhppote-cli set-listener 405419896 192.168.1.100:60001

The reason you're seeing occasional events is that there is a background process that retrieves "missing" events from the controller, but the interaction with the Home Assistant poll cycle and event handling makes it more than a bit unintuitive.

re. existing swipe records. It's possible except that I have no idea where to store them Home Assistant (am open to suggestions though). I did experiment a bit but hass timestamps events when it receives them so the built-in event logs make no sense whatever doing it that way.

m0vse commented 8 months ago

Perfect, set-listener has sorted it! I assume the controllers only send an unlock event as the doors show as unlocked until the next poll (30 seconds) is this correct?

I was a bit concerned about using 'early Alpha' software but since the Windows software stopped working, I have been managing them manually using the internal web interface on each controller, which is a bit painful, so I thought even if it is only 1/2 working, it must be better than that!

I assume the set-listener setting is persistent on the controllers (or do I need to set it again after a controller reboot?)

I will have a think about the existing swipe records, but I am a bit new to HA so still learning.

Thanks again

Phil

uhppoted commented 8 months ago

Oh great!! Very glad it was that and not something completely weird, and yes, you're completely correct - the controller only generates an unlocked event, the locked event is a synthetic event that is generated from the poll data.

The controller event listener setting is persistent across power cycles, etc, so it only needs to be set once - although I may add a controller-unconfigured event/entity/somesuch so that at least there is some kind of notification if it isn't set. Still thinking about how best to do it though...

re. early Alpha. <smile> I shall try not to break anything.

re. I am a bit new to HA so still learning. Likewise - it's been quite a learning curve :-)

I'm going to leave this issue open until I have something in place to set/monitor the controller event listener setting - will post an update here when it's available.

m0vse commented 8 months ago

Sorry, I have a few more questions!

I notice in the logbook, the time/date is being set on both controllers every 30 seconds, is this normal? I know the RTC on them isn't that great, but is that something that should be set a bit less frequently, or am I missing something?

Also, is there a way to interrogate the system to find who has opened which door when?

Thanks

Phil

uhppoted commented 8 months ago

Hi,

The wording of the log message is a bit misleading - it is updating the Home Assistant controller date/time entity with the controller date/time every 30 seconds (or whatever poll interval you choose to configure). The actual controller date/time is only set when you change it via the uhppoted.controller.{controller}.datetime entity. I'll change the log message to read something like "fetching controller date/time" to avoid confusion.

re. who/what/when. The controller doesn't natively support access queries because it's only a small microcontroller with limited capability. It's also reasonably unlikely that the Home Assistant custom component ever will - hass just doesn't include the UI elements to implement something like that (at least not at the moment anyway).

A tool to query and analyse the event logs is on the TODO list but it's not going to happen anytime soon barring a 3AM stroke of genius - it is surprisingly complicated and difficult to do well! In the interim however, there are a couple of other other options:

uhppoted commented 7 months ago

Hi,

I'm going to close this out - the latest alpha release includes the ability to configure the destination address for controller events and will set it automatically if it is incorrect.

Thanks for braving the early alpha release :-)