Have you upgraded to the latest supervisor? That is what eliminated the blank config for me - I still can’t use the add-on because of the UnhandledPromiseRejection but I believe that the problem with the supervisor is fixed.
I think I am seeing the same issue, from my log the following after a shutdown and restart of HA.
(node:6) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'port' of undefined
at setDefaults (/snapshot/app/dist/config.js:18:96)
at Object.loadConfig (/snapshot/app/dist/config.js:65:16)
at /snapshot/app/dist/index.js:18:29
at Generator.next (<anonymous>)
at /snapshot/app/dist/index.js:8:71
at new Promise (<anonymous>)
at /snapshot/app/dist/index.js:4:12
at /snapshot/app/dist/index.js:17:8
at Object.<anonymous> (/snapshot/app/dist/index.js:57:4)
at Module._compile (pkg/prelude/bootstrap.js:1320:22)
(node:6) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:6) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
After much delay I bit the bullet, updated firmware on my 48W-Live, installed Smartcom on Com1/2 and ComIP on Com3 and had a go at getting this addon running.
Got it logged on and it’s pulling sensors through so happy days so far, eek! I’m disproportionally excited about this.
It was all working perfectly but I failed to read the latest posts - Updated supervisor this afternoon and now have the same issue as above, all sensors stuck in last known state from 6+ hours ago.
Aside from this issue, super happy with the add-on
Yup - same boat. Seemed to die for me after disabling the alarm this morning, don’t believe there were any updates overnight although I do have the add-on to autoupdate but not HA/supervisor, so of course I went to update docker-ce, supervisor etc and ended up worse
If it I understand correctly, the current work around is to deploy the addon into a non-HA docker environment?
I find a server (not just HA) reboot normally solves this. This is one reason I want to move to Debian, to get onto a more supported platform. Whenever they update Supervisor it goes unhealthy.
I’m seeing the same problem as @AGW and @MarkB1. issue started earlier today - thought updating to core 2021.2.2 might help but it didn’t.
glad I’m not the only one.
Is this a supervisor update issue?
(node:6) UnhandledPromiseRejectionWarning: TypeError: Cannot read property ‘port’ of undefined
at setDefaults (/snapshot/app/dist/config.js:18:96)
at Object.loadConfig (/snapshot/app/dist/config.js:65:16)
at /snapshot/app/dist/index.js:18:29
at Generator.next ()
at /snapshot/app/dist/index.js:8:71
at new Promise ()
at /snapshot/app/dist/index.js:4:12
at /snapshot/app/dist/index.js:17:8
at Object. (/snapshot/app/dist/index.js:57:4)
at Module._compile (pkg/prelude/bootstrap.js:1320:22)
(node:6) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see Command-line API | Node.js v21.6.2 Documentation). (rejection id: 1)
(node:6) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
I am starting to work on a reverse engineered implementation of the Wintex protocol, based on a decompiled Android RKP app, as well as analysis of the protocol used by the Wintex app itself. I’m referring to a “Wintex” protocol because the Android RKP app uses Globals.UseWintexProtocol, even though I have not actually seen other references online to such a beast, only Simple and Crestron, et al.
So far I have implemented the following functions using the Wintex protocol:
login
heartbeat
getPanel - matches the version string to return a Java enum that contains the relevant properties of the connected panel, number of zones, partitions, users, etc.
getPersistentMemory(addr, length)
getTransientMemory(addr, length)
getLCDText - uses getTransientMemory
getZoneText - uses getPersistentMemory
hangup
The ultimate intention is to implement the entire protocol inside of ESPHome on an ESP32, as described in this post: Texecom Alarm panel. A TCP port will be exposed to support Wintex and phone apps using one COM port, and the other COM port will be used by ESPHome to provide zone sensor updates, alarm status, etc using the HA API and/or MQTT.
While I understand that Texecom has asked you (@dchesterton) not to provide source due to the protocol NDAs you have signed, would it be possible to share a stripped down framework of the app that includes no actual protocol implementation at all? i.e. just stub/mock functions? That would save an enormous amount of duplicated effort on my part, and would accelerate support for plain old Premier (non-Elite) panels.
I’m not sure whether you have received any documentation for the Wintex protocol, but if not, perhaps replacing the current simple/crestron protocol implementation with a Wintex implementation would allow you to bypass the NDA’s and move development out into the open?
