node-red-contrib-ccu 4.5.0

v4.5.0

on Node.js NPM

Added

• TLS and authentication for every connection to a CCU on the network
  (task 5, #27). With TLS/SSL on, all XML-RPC interfaces are reached over
  the CCU's TLS ports (42000, 42001, 42010, 49292; CCU-Jack 2122), the ReGaHSS
  over 48181 and openccu-lite's metadata api over 443; with Authentication
  on, the username and password go out as HTTP basic auth on every call, the
  init included, to every XML-RPC interface and the ReGaHSS. Both are the
  CCU's web server's - a CCU3 switches them on in its firewall settings,
  openccu-lite under remote access. A local connection (Node-RED on the
  system, localhost / 127.0.0.1) reaches the interface processes directly
  on the loopback and uses neither, whatever the dialog says: https to a plain
  port or credentials in a BIN-RPC frame only broke the connection before;
  the dialog hides the fields for a loopback address and says so. BIN-RPC has
  neither: with TLS on, BidCos-RF goes XML-RPC over TLS even when the hidden
  bcrfBinRpc property asked for BIN-RPC (a warning names it); CUxD's BIN-RPC
  never has them. Node-RED's own callback server for the CCU's events stays
  plain HTTP - the CCU presents no credentials and cannot verify our
  certificate; the help text says so and asks for a firewall rule on the
  Node-RED host. Ticking Authentication ticks TLS/SSL with a notice in the
  editor instead of a browser alert. Without Ignore invalid TLS
  certificates, the CCU's self-signed certificate is refused, as before.

• One topic template in every node that emits, the value node's input
  takes the emitted shape (task 6, #39 @psi-4ward). The get value node has a Topic
  field now, the same ${…} template as rpc-event, value, sysvar, program,
  rpc and script; empty (the default, and every existing flow) leaves
  msg.topic as it came in. The value node's input accepts a datapoint
  address in msg.topic in the shape the nodes emit
  (ccu3/BidCos-RF/OEQ1868878:1/STATE, hm/BidCos-RF/OEQ1868878:1/STATE: the
  last three slash-separated segments) besides the old
  BidCos-RF.OEQ1868878:1.STATE, so an event's topic can be fed straight back.
  No default changed: whoever wants one scheme everywhere enters e.g.
  hm/${Interface}/${channel}/${datapoint} in each node; the README's Topics
  section lists the defaults and the placeholders, the help texts of
  rpc-event, value and get value the placeholders.

• Help texts for every node in German and English, as locale files
  (task 7, #58). The help moved from inline blocks in the node files into
  nodes/locales/de/ and nodes/locales/en-US/, the layout Node-RED
  documents for node help: the runtime serves one language's text per
  request through the same lookup as its own nodes (de and de-DE both
  get the German text, everything else the English one) instead of shipping
  every language's block with the node. German is the source; the English texts of the connection,
  value, rpc-event, set-value, sysvar and switch nodes, which were missing or
  one-line stubs, are complete now, the mqtt node's help describes its topics,
  commands and payload formats in both languages, the set-value node's German
  configuration list (empty bullets since 3.x) and the rpc-event node's output
  section are written, and the value nodes link the eQ-3 HmIP device
  documentation for what a datapoint means (@lolli78). A unit test guards
  that every node has both files, that neither is a stub, and that no inline
  help is left.

Fixed

• Writing one party-mode datapoint of an HmIP thermostat reset the other
  two (task 2, #156 @ben-5555, #161 @lolli78). An HmIP eTRV/WTH takes
  PARTY_TIME_START, PARTY_TIME_END and PARTY_SET_POINT_TEMPERATURE only
  together: a setValue of one of them put the others back to
  1999_11_30 00:00, so party or holiday mode could not be set from the
  value nodes at all. A write to one of the three through the value or
  set-value node now goes out as one putParamset on VALUES with all
  three, the other two taken from our own last write, the value cache or a
  getParamset read of the channel - the way the WebUI writes them. The two
  times may be given as the device's YYYY_MM_DD HH:MM string, a JavaScript
  Date, an ISO string or epoch milliseconds; they are formatted for the device
  in local time. Any other datapoint of the channel is written as before. The
  older HM thermostats (PARTY_MODE_SUBMIT) are not covered.
• A callback call with an unknown interface id ended Node-RED (B-32).
  Anything on the system can connect to the connection's callback ports on
  the loopback; a system.listMethods without parameters, an event with an
  id that is not one of ours, or a newDevices list with a malformed entry
  threw inside the RPC server's handler, which runs from an event emitter -
  an uncaught TypeError, and the whole Node-RED process exited. Such a call
  is now answered with an empty result (the method list for
  system.listMethods) and logged at debug; a throw inside a handler is
  logged as an error and answered instead of ending the process.
• A metadata api detection that timed out at start left the connection in
  ReGa mode for good (B-28). On openccu-lite the connection asks
  GET /api/meta/v1/version once at start; when that probe ran into its 5 s
  timeout - on a Raspberry Pi 3 Node-RED's own start blocks the event loop
  long enough for that at every start, on a busy system now and then - the
  connection settled for the ReGaHSS, the ReGa polls failed every 30 s and
  names, rooms and functions stayed empty; the only re-detection ran from rare
  error paths, at most every five minutes. A timeout, a refused connection or
  a 502/503/504 is now taken as "not decided": the ReGa path starts as before,
  the detection is repeated after 1, 2, 4, 8 s and then every 15 s (up to 20
  times, then the five-minute rule again), and the failing ReGa poll asks for
  a re-detection too. A CCU's 404 is still a conclusive "no".
• After an hmipserver restart HmIP-RF events stopped for up to ten minutes
  (B-29). hmipserver forgets its clients when it restarts and does not tell
  them: the init had succeeded, nothing failed, and the events simply stopped
  until the 600 s silence timeout called init again. The connection now
  pings HmIP-RF after 30 s without an event and, when no event (the PONG)
  arrives within 10 s, subscribes again at once - the interface shows
  waiting meanwhile, one warning names the reason, and the retry of 4.4.4
  covers the time the process is down. A newDevices from the restarted
  hmipserver (it sends one about 16 s in) triggers the ping right away, so
  events are back well within a minute. An interface that never delivered an
  event since its init is not re-subscribed on a missing PONG alone.
• A queued write of the same set point was dropped after the actuator had
  been operated by hand (B-19, #151 @vigeland). The value node's Queue compared the
  new value with the value cache, and the cache of a control channel
  (HmIP-FROLL/BROLL :4, the status lives in :3) holds the echo of our own
  last write for good - a blind moved by hand reports no new set point there,
  so the same 1 could never be sent again while Homematic Manager moved the
  blind at once. A cached value that is the echo of our own last write no
  longer dedupes; only a value from another source does. The value node has a
  Force option (and msg.config.force), as set-value has it; set-value's
  own pre-check no longer drops a forced write when the cache already holds
  the value.

Security

• The CCU password and the openccu-lite token were stored in plain text in
  flows.json and went out with every exported flow (B-31). Both are
  Node-RED credentials now (flows_cred.json, encrypted, never exported).
  A flow written before this version still carries them as plain properties:
  the connection uses them once, moves them into the credentials and warns;
  the editor no longer knows the two properties, so the next deploy removes
  them from flows.json. Nothing to do by hand.

Changed

• The device table follows the CCU, and can be re-read by hand (task 9,
  #146 @guny74, #181 @vore). A device or channel the CCU reports with another TYPE,
  VERSION or FIRMWARE than the cache holds replaces the cached entry, leaves
  its old type list and gets its datapoints fetched again - a channel whose
  type changed in place kept its old datapoints before, until the cache file
  was deleted. The connection node's dialog has a Re-read device data
  button that asks every connected interface for its device list again
  (new and changed devices get their datapoints, removed ones go) and
  reports what changed. The editor's channel pickers no longer empty the
  configured channel when the connection is still initialising: they show
  loading device data and ask again.
• An interface without devices is watched too (task 9, old B-11). The
  ping watchdog returned early for an interface with no devices in the
  cache, so such an interface never pinged and never re-initialised after a
  CCU reboot. It pings now, and re-initialises after the ping timeout once
  it has ever delivered an event (a PONG counts) - a process that answers no
  ping at all is not asked to init every timeout.
• The listDevices answer to hmipserver lists the CCU's virtual remote
  control (HmIP-RCV-1) again (task 13). It was left out since CCU3 firmware
  3.43.15 (2019), whose hmipserver failed on an answer that held it; current
  hmipservers take it, and without it every init made hmipserver log a
  handleIDMigration warning and send the whole virtual remote (52
  descriptions) again with newDevices.

Commits since v4.4.5

• 4.5.0 - TLS and authentication for remote CCUs, party mode, device table re-read, help texts, callback and liveness fixes (4be79e9)
• Help texts for every node in German and English, as locale files (task 7, #58) (0287001)
• Party mode on HmIP thermostats: one datapoint written means all three go out in one putParamset (task 2, #156, #161) (8222e97)
• One topic template in every node that emits, the value node's input takes the emitted shape (task 6, #39) (ac67320)
• TLS and authentication for every connection to a CCU on the network (task 5, #27) (9253d07)
• Device table: changed devices are taken over, a re-read button, pickers that wait, the watchdog for device-less interfaces (task 9) (725dbfb)
• listDevices lists the virtual remote control (HmIP-RCV-1) again (task 13) (a9e191e)
• test: wait for the event stream before sending an event to the provider (B-30) (fcc1147)
• The CCU password and the openccu-lite token are Node-RED credentials, not flow properties (B-31) (ad5ff52)
• Queued writes: the echo of our own write does not dedupe, force on the value node (B-19, #151) (b66a03f)
• HmIP-RF liveness: a ping every 30 s without an event, init again when no PONG comes within 10 s (B-29) (2f75934)
• An inconclusive metadata api detection at start is repeated instead of settling for the ReGa (B-28) (efe4141)
• Callback calls with an unknown interface id are answered, never thrown on (B-32) (c950935)