const.py 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259
  1. """Constants for the Solar of Things integration."""
  2. DOMAIN = "solar_of_things"
  3. # ─── Configuration keys ────────────────────────────────────────────────────────
  4. CONF_IOT_TOKEN = "iot_token" # legacy / advanced manual entry
  5. CONF_STATION_ID = "station_id"
  6. CONF_DEVICE_ID = "device_id"
  7. CONF_TIME_ZONE = "time_zone"
  8. # Credential-based auth (preferred)
  9. CONF_USER_ID = "user_id" # Siseli account / user-ID login (not email)
  10. CONF_PASSWORD = "password"
  11. # Fields that are typed or copy-pasted by hand and routinely arrive with stray
  12. # leading/trailing whitespace. The upstream API treats " 4235…" as a different
  13. # (invalid) value, which surfaces to the user as an unhelpful "cannot connect".
  14. # Consumed by normalise_config_fields() in util.py, which is applied both when
  15. # the config flow accepts input and when an entry is read back at setup, so a
  16. # single list keeps the two paths from drifting.
  17. # CONF_PASSWORD is deliberately absent: whitespace in a password may be
  18. # significant, so it is never trimmed.
  19. WHITESPACE_SENSITIVE_FIELDS = (
  20. CONF_USER_ID,
  21. CONF_STATION_ID,
  22. CONF_DEVICE_ID,
  23. CONF_IOT_TOKEN,
  24. CONF_TIME_ZONE,
  25. )
  26. # Runtime-stored token state (written back to config entry)
  27. CONF_REFRESH_TOKEN = "refresh_token"
  28. CONF_ACCESS_TOKEN_EXPIRES = "access_token_expires" # ISO-8601 string
  29. CONF_REFRESH_TOKEN_EXPIRES = "refresh_token_expires" # ISO-8601 string
  30. # ─── API bases ─────────────────────────────────────────────────────────────────
  31. # Both auth and data endpoints live on the production server solar.siseli.com.
  32. # The portal JS bundle embeds both test/prod AppIDs; AppID rBrTRfAPXz is the
  33. # one accepted by solar.siseli.com (confirmed by live API testing 2026-03-07).
  34. API_BASE_URL = "https://solar.siseli.com" # data endpoints
  35. API_AUTH_BASE_URL = "https://solar.siseli.com" # auth / login endpoints
  36. # ─── Auth endpoints (discovered from portal JS bundle) ─────────────────────────
  37. # The login endpoint requires IOT-Open-AppID signing (see api.py _sign_request).
  38. API_LOGIN = "/apis/login/account" # POST + signed headers
  39. API_REFRESH_TOKEN = "/apis/login/refresh/access/token" # POST, no token needed
  40. # ─── IOT Open Platform app credentials (embedded in portal umi.js) ────────────
  41. # rBrTRfAPXz is the production AppID accepted by solar.siseli.com.
  42. # JO4DAiNeys is the test AppID (accepted only by test.solar.siseli.com).
  43. IOT_APP_ID = "rBrTRfAPXz"
  44. IOT_APP_SECRET_ENC = "I4D0KRr2339z3pQ/at91V9BpFAOe54DaTafwSm6suIQ="
  45. # ─── Data endpoints ────────────────────────────────────────────────────────────
  46. API_TIME_SERIES = "/apis/deviceState/simple/attribute/keys/history/v1"
  47. API_MONTHLY_SUMMARY = "/apis/stationOverView/stateAttributeSummary/category/yearly"
  48. # Remote device config endpoints (discovered 2026-03-07 from live API testing).
  49. # These accept a plain IOT-Token header (no IOT-Open-Sign) and use the device ID
  50. # as a query parameter. Write sends one setting key+value per call.
  51. API_SETTINGS_GET = "/apis/remote/device/configs/cache/get" # ?deviceId=<id>
  52. API_SETTINGS_SET = "/apis/remote/device/config/write" # ?deviceId=<id>
  53. API_DEVICE_LIST = "/apis/device/list"
  54. # Live "energy flow" endpoint. GET with ?deviceId=<id>&dataSource=1; values are
  55. # returned under data.deviceAttributeState.fields. Used as a fallback when the
  56. # historical time-series endpoint yields nothing (see ENERGY_FLOW_RULES below).
  57. API_ENERGY_FLOW = "/apis/deviceState/simple/energy/flow/v1"
  58. # ─── Token refresh window ──────────────────────────────────────────────────────
  59. # Refresh the access token this many seconds *before* its stated expiry.
  60. # Mirrors the portal JS which refreshes when ≤300 s remain.
  61. TOKEN_REFRESH_LEAD_SECONDS = 300 # 5 minutes
  62. # ─── Sensor keys ───────────────────────────────────────────────────────────────
  63. SENSOR_KEYS = [
  64. "pvInputPower",
  65. "acOutputActivePower",
  66. "batteryDischargeCurrent",
  67. "batteryChargingCurrent",
  68. "batteryVoltage",
  69. "feedInPower",
  70. "batteryPower",
  71. "batterySOC",
  72. "gridPower",
  73. "loadPower",
  74. ]
  75. # ─── Energy-flow fallback mapping ──────────────────────────────────────────────
  76. # Several inverter / WiFi-dongle firmware families never populate the historical
  77. # time-series endpoint (API_TIME_SERIES) that this integration reads by default,
  78. # so every realtime sensor stays "unknown" while the portal shows live data.
  79. # Reported for UWB1, RWB1-0x, JC-62xx, DatouBoss DT-series and EASUN units in
  80. # https://github.com/Conexo-Casa/solar-of-things-ha/issues/7 (and #3, #8, #11,
  81. # #14, #15). Those devices serve live values from API_ENERGY_FLOW instead,
  82. # under a different set of field names.
  83. #
  84. # Each canonical sensor key maps to an ordered list of rules. The first rule
  85. # that produces a usable number wins. A rule is (mode, source_fields, scale):
  86. # "first" – use the first source field that is present
  87. # "sum" – add every source field that is present (multi-string PV inputs)
  88. # `scale` converts the source value into the unit declared in
  89. # SENSOR_DEFINITIONS.
  90. #
  91. # ONLY mappings whose unit is confirmed by a NON-ZERO observed value are enabled
  92. # here. Every rule below has scale 1.0 — the value is published exactly as the
  93. # portal reports it — so no rule in this table can be 1000x wrong. The issue #7
  94. # payload was captured at night, so it pinned down the units of only these
  95. # fields:
  96. # bmsBatteryVoltage / positiveTerminalBatteryVoltage 26.6 V
  97. # batteryPercentage / bmsSOC 100 %
  98. # batteryPower 9 W
  99. # pv1Power / pv2Power W (labelled; 0 at night)
  100. # Anything that would need a kW→W conversion, or whose direction/sign is
  101. # ambiguous, is listed in ENERGY_FLOW_UNVERIFIED below and left unmapped until a
  102. # daytime, under-load capture confirms it.
  103. ENERGY_FLOW_RULES: dict[str, list[tuple[str, tuple[str, ...], float]]] = {
  104. "pvInputPower": [
  105. ("sum", ("pv1Power", "pv2Power", "pv3Power", "pv4Power"), 1.0),
  106. ],
  107. "batteryVoltage": [
  108. ("first", ("bmsBatteryVoltage", "positiveTerminalBatteryVoltage"), 1.0),
  109. ],
  110. "batterySOC": [
  111. ("first", ("batteryPercentage", "bmsSOC"), 1.0),
  112. ],
  113. "batteryPower": [
  114. ("first", ("batteryPower",), 1.0),
  115. ],
  116. }
  117. # Fields observed in the issue #7 payload that are deliberately NOT mapped.
  118. # Publishing a wrong value is worse than leaving a sensor "unknown": a 1000x
  119. # scaling error feeds the HA Energy dashboard and long-term statistics, and
  120. # statistics cannot be un-poisoned by a later fix. Two distinct reasons:
  121. #
  122. # 1. UNIT UNCONFIRMED (kW vs W). Every captured sample was zero because the
  123. # reading was taken at night, so the scale cannot be pinned down. The
  124. # reporter labelled these kW, and this integration already applies kW→W to
  125. # acOutputActivePower on the time-series path, so x1000 is *probably* right —
  126. # but "probably" is not good enough for a value that lands in statistics.
  127. # 2. DIRECTION UNCONFIRMED. The battery terminal currents carry the right
  128. # magnitude (26.6 V x 0.4 A ~= 9 W, matching the reported batteryPower), but
  129. # which terminal means charge and which means discharge is unverified — the
  130. # reporter flagged it, and a swap would invert charge/discharge, which is
  131. # actively misleading rather than merely absent.
  132. #
  133. # Revisit once two captures from issue #7 are available: one in daylight under
  134. # load (settles the units), one while the battery is actively charging (settles
  135. # the direction).
  136. ENERGY_FLOW_UNVERIFIED: tuple[str, ...] = (
  137. # 1. unit unconfirmed (kW vs W)
  138. "aPhaseMainsPower", # candidate for gridPower (sum of the three phases)
  139. "bPhaseMainsPower",
  140. "cPhaseMainsPower",
  141. "generationPower", # candidate aggregate fallback for pvInputPower
  142. "load_power", # candidate for loadPower / acOutputActivePower
  143. "loadPower",
  144. # 2. direction unconfirmed (which terminal is charge vs discharge)
  145. "positiveTerminalBatteryCurrent",
  146. "negativeTerminalBatteryCurrent",
  147. )
  148. # Canonical keys that indicate the time-series endpoint returned usable realtime
  149. # data. If none of these are present the energy-flow fallback is attempted.
  150. REALTIME_PROBE_KEYS: tuple[str, ...] = (
  151. "pvInputPower",
  152. "acOutputActivePower",
  153. "batteryVoltage",
  154. "batterySOC",
  155. "batteryChargingCurrent",
  156. "batteryDischargeCurrent",
  157. "feedInPower",
  158. )
  159. SENSOR_DEFINITIONS = {
  160. "pvInputPower": {
  161. "name": "PV Input Power",
  162. "unit": "W",
  163. "device_class": "power",
  164. "icon": "mdi:solar-power",
  165. },
  166. "acOutputActivePower": {
  167. "name": "AC Output Power",
  168. "unit": "W",
  169. "device_class": "power",
  170. "icon": "mdi:power-plug",
  171. },
  172. "batteryDischargeCurrent": {
  173. "name": "Battery Discharge Current",
  174. "unit": "A",
  175. "device_class": "current",
  176. "icon": "mdi:battery-arrow-down",
  177. },
  178. "batteryChargingCurrent": {
  179. "name": "Battery Charging Current",
  180. "unit": "A",
  181. "device_class": "current",
  182. "icon": "mdi:battery-arrow-up",
  183. },
  184. "batteryVoltage": {
  185. "name": "Battery Voltage",
  186. "unit": "V",
  187. "device_class": "voltage",
  188. "icon": "mdi:battery",
  189. },
  190. "batteryPower": {
  191. "name": "Battery Power",
  192. "unit": "W",
  193. "device_class": "power",
  194. "icon": "mdi:battery-charging",
  195. },
  196. "batterySOC": {
  197. "name": "Battery State of Charge",
  198. "unit": "%",
  199. "device_class": "battery",
  200. "icon": "mdi:battery",
  201. },
  202. "feedInPower": {
  203. "name": "Grid Feed-in Power",
  204. "unit": "W",
  205. "device_class": "power",
  206. "icon": "mdi:transmission-tower-export",
  207. },
  208. "gridPower": {
  209. "name": "Grid Import Power",
  210. "unit": "W",
  211. "device_class": "power",
  212. "icon": "mdi:transmission-tower-import",
  213. },
  214. "loadPower": {
  215. "name": "Load Power",
  216. "unit": "W",
  217. "device_class": "power",
  218. "icon": "mdi:home-lightning-bolt",
  219. },
  220. # Monthly summary sensors
  221. "monthly_pv_generated": {
  222. "name": "Monthly PV Generated",
  223. "unit": "kWh",
  224. "device_class": "energy",
  225. "icon": "mdi:solar-power",
  226. },
  227. "monthly_grid_import": {
  228. "name": "Monthly Grid Import",
  229. "unit": "kWh",
  230. "device_class": "energy",
  231. "icon": "mdi:transmission-tower-import",
  232. },
  233. "monthly_total_consumption": {
  234. "name": "Monthly Total Consumption",
  235. "unit": "kWh",
  236. "device_class": "energy",
  237. "icon": "mdi:home-lightning-bolt",
  238. },
  239. "monthly_solar_percentage": {
  240. "name": "Monthly Solar Coverage",
  241. "unit": "%",
  242. "icon": "mdi:percent",
  243. },
  244. }