![]() ![]() timer info is pulled by the server.After resetting the DVR / NVR password, you MUST follow the steps below to remove and add the device to the Night Owl Connect App. So there's a lot of flexibility as to what can be checked/changed with it, much more so than is offered in the app.Īlso I suspect that the cycling couple of high bits in "status B" that increment every time a setting changes is possibly to inform the server that it needs to refresh the config data so that e.g. I've found the "advanced settings PIN", display backlight timeout, contrast settings, CT configuration, generation icon, heater type icons, export threshold and margin etc. It seems you can get at (almost?) all settings. Because of the way the protocol works, if you have the app open whilst adjusting settings on the devices, the app might overwrite the settings thus undoing them. Presumably this is to avoid wearing out whatever kind of memory is used for storing the settings. I assume 2 of these are for the relay add-in board (which I don't have.) The annoying thing is that changing things in the app doesn't seem to have an immediate effect - it lags behind by a few minutes. I used to assume that the low byte of "status A" would have 0x80 set if it was a zappi, this turns out to be a heater type flag for eddi so there must be some other way to detect the device type.Įxamining the memory used for eddi's config data, there seems to be 4 sets of timers (4 timers each). Documented some memory addresses used for configuration data Cleaned up table of values for low byte of "status A" as it is a combination of flags and packed values Added tables of heater types for eddi (these are encoded in status A) Added heatsink temperature to historical data, along with corresponding values for "nect#" and "pect#" Merged common parts of eddi/zappi historical data structures I'll update tomorrow.ĭocumentation updated (no scripts uploaded yet other than my dummy server that just replies to everything it receives). ![]() Looking at the API now the data for one of my Zappis is complete for the day, but the other one (the master) has no data from 08:00 through to 13:00 today which is a fairly occurrence, and why I think for the most part the API is useless, I wonder if this would fill in if I was to stop my server overnight. Interesting about the app-is-open flag, I knew the server light can indicate the app is open so it had to be there. Is there an easy way to evesdrop in on the comms between the client and server? I've got a body of work that works with the API to do some cool stuff but I'm waiting on approval to publish, but I can take a look at yours and see if I can help. I could take a look if you are able to publish it. One nice thing is if you set the "app is open" flag in the server responses, the hub will send data out every second, which is ideal if you're doing your own local data logging/monitoring. I'm gradually implementing parsing for all of this in a Python script but it's slow going as I am often stopping to stuff some hex dumping into the routines I'm writing so I can see how changing settings etc. Something else is also packed into the "day of month" (which is also 5-bits) but I'm not sure what. ![]() I switch off the zappi.Īpr 03, 2020Yep - the day of week is a 3-bit value and the hour is a 5-bit value, they are packed into the same byte. Kinda odd that these aren't sent out in the eddi structure - I don't think it will be sent if e.g. The values for "pect1", "nect1" and "nect2" are present at the end of the zappi structure and are also divided by 60 (hence they're always things like 120, 480, 720 etc.) Looks like there is room to accommodate a pair of values for 3 CTs. It does not look like the structures for historic data contain any CT values. whereas the data submitted by the hub reports these values: For example, for 22:22 BST today (21:22 UTC) the web API reports: ![]() I've made some further progress on this and have now found that the historic data also includes temperature data, and a number for the "day of week".Ĭomparing this to the data available at the web APIs, it looks like the server is multiplying the values it receives from the hub by 60. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |