Time to a little update on how things is progressing:
I believe I have found and solved the issue with IsAlive going OFF.I my test setup it has been running for 1,5 hour without turning OFF
I have been investigating how the binding should act when running the monitor in a continous recording mode (eg. Mocord or Record). Currently my approach has been to connect to listen to port 6802 for events being published there, so that I donât have to poll the API for changes. It turns out that this approach, doesnât allow me to show correct state at all times.
The problem is, that when starting continous recording, a start event is sent, but right away two stop events is being sent. If I query the API, an event is still active until I stop recording. whenever I stop recording I receive another stop event, which is just fine. When reading the documentation it seems to be the expected/described behaviour.
The problem is that I solely uses the event on port 6802 to trigger start / stop of an event, which I obviously canât. I have looked at how zmNinja deals with this, and it seems that the API is being polled. I would really like to avoid polling, but I donât see any possibility for avoiding it. I will add a new channel that contains the state as shown in both ZoneMinder and zmNinja (five states 0=Idle, 1=pre-alarm, 2=alarm, 3=alert, 4=recording)
I have also looked a the channels that is currently defined in the monitor, especially because Kai pin pointed that static information shouldnât be in an channnel / item, that should be moved to a property. With that in mind I have looked at my channels an I will remove channels:that has static or almost static information, for the monitor this is name and sourcetype.
channels will be renamed to reflect the contents of the channel. I suggest the following channel lineup for a monitor thing:
- is-alive (switch)
- enabled (switch)
- alarmed (switch) (previously trigger-event)
- recording (switch)
Advanced channels
- function (String) (None, Modect, Monitor, Mocord, Record, Nodect)
- event-status (Number) (Either 0: idle, 1: pre-alarm, 2: alarm, 3: alert, 4: recording)
- event-cause (String: , Signal, Motion, Continous, openHAB, Other)
- status-capture-daemon (Switch) - previously daemon-capture-state
- status-analysis-daemon (Switch) - previously daemon-analysis-state
- status-frame-daemon (Switch) - previously daemon-frame-state
The following channels will be removed, as I think they contain amore or less useless text string:
daemon-capture-statustext
daemon-analysis-statustext
daemon-frame-statustext
With the above changes it should be possible to get the same information as displayed in ZoneMinder /zmNinja, as well as a indication of the event cause (signal, motion etc).
Hopefully this channel lineup would be satisfactory for most of you? At least I believe that I are getting enough information.
Unfortunately this reuires some rework in the code, but I think this will be needed for things to work properly.