zwave-js / node-zwave-js Goto Github PK

View Code? Open in Web Editor NEW

741.0 741.0 593.0 97.89 MB

Z-Wave driver written entirely in JavaScript/TypeScript

Home Page: https://zwave-js.github.io/node-zwave-js/

License: MIT License

TypeScript 99.49% JavaScript 0.41% Batchfile 0.01% Shell 0.08% PEG.js 0.03%

hacktoberfest iot razberry smart-home wireless z-wave zwave

node-zwave-js's Introduction

Z-Wave device driver written entirely in JavaScript/TypeScript

📡 Control your Z-Wave network from Node.js
👶 Easy high-level API
😊 Just JavaScript ^{(or rather TypeScript)}, no static library mess
🔥 blazing fast

Intro

Z-Wave is an amazing piece of technology, but it is difficult to get started with and develop for.
It shouldn't be! We've got you covered.

Built on Node.js and compatible with all known 500, 700 and 800 series Z-Wave controller hardware adapters, Z-Wave JS runs on almost anything with a little bit of computing power and a serial port. Check out the documentation to get started!

Quick Links

License · Changelog · Documentation · Device configuration DB

Supporting Z-Wave JS

Started in 2018, Z-Wave JS has breathed new life into the Z-Wave ecosystem and is now powering thousands of smart homes all over the world. We strive to build the best open source Z-Wave device driver out there and hold ourselves to the highest standards.

If you'd like to help support the future of the project and make the Z-Wave world a better place, please consider:

Contributing configuration files for new devices, so we have our hands free for the actual development.
Sending us devices to test. Working with an actual device is much more efficient than trying to debug with logfiles.
Giving funds by becoming a supporter. Personally or with your company, monthly or one-time - every little bit helps. Read more...

Top Sponsors:

node-zwave-js's People

Contributors

Stargazers

Watchers

Forkers

husky-koglhof mpreisinger sieukrem amcasey robertslando aamiri755 larstobi ahochsteger awulf jaburges paularmstrong firstof9 jcam laplaceii cgarwood blhoward2 starfleetcptn michsior14 balloob mattstocum towerhand pascalwinters juli3nas nathanfiscus inovelliusa itewk grizzlyjere jarrettv cefinger sneelco senorchris stuartwishart wauswaus matheus2308 helidude ibddot jeremyrea roflmao overzealous hufftheweevil madj42 scyto jeroenvandezande maikelvallinga aneisch technikte petro31 gunsmithy loe wesleylima otaku mdoggydog txag1995 ikcelaks raman325 rccoleman prwood80 bepsoccer wizkid akamel001 drobtravels sybohy derekyle nyzack warthog9 sartirious abmantis kvs ledfoot775 junster1 bburan fletchan alarobric matejdro inoy-d nixon506e gyorsok smitterson santafox uberdoward masonevans foulek57 wraul jjlawren dukk markus-li chr1stian rikdc ahertz jamesdawson3 justindthomas brettjonesoz kanebullen chrisromp dkeeper faspina simong-gh leonseng qpasatio d1b

node-zwave-js's Issues

Finish Configuration CC

Add a way to target a specific endpoint with the CCAPI

Add JSDoc comments to more methods

Add a unified driver mock that works in all tests

Limit VersionCCGet to implemented version > 1

SDS14223-7:

If the controlling node controls only version 1 of a given Command Class, it may skip requesting the supporting node version for the actual Command Class.

==> lib/node/Node.ts, in queryCCVersions()

Add an API to set values on the nodes directly

e.g.

node.setValue({
  commandClass: 4,
  endpoint: 1,
  propertyName: "something",
  propertyKey: 1,
}, "new value");

would determine the correct CC command and send it to the node.

Investigate how to handle branded "unknown" in the external API

Make sure every CCCommand has a deserialization branch

even if it is not implemented

[Tracking] Implementation status of Command Classes

	CC name	Version	Interview?	API?	setValue?	pollValue?
✔	Alarm Sensor (deprecated)	1 (1)	✔	✔	✔	❌
❌	Alarm Silence	- (1)	❌	❌	❌	❌
❌	Anti-Theft Unlock (deprecated)	- (1)	❌	❌	❌	❌
❌	Application Status	- (1)	❌	❌	❌	❌
✔	Association	4 (4)	✔	✔	✔	❌
❌	Association Command Configuration	- (1)	❌	❌	❌	❌
✔	Association Group Information	3 (3)	✔	✔	✔	❌
❌	Authentication	- (1)	❌	❌	❌	❌
❌	Authentication Media Write	- (1)	❌	❌	❌	❌
✍🏻	Barrier Operator	1 (1)	✔	✔	❌	❌
✍🏻	Basic	2 (2)	✔	✔	❌	❌
❌	Basic Tariff Information	- (1)	❌	❌	❌	❌
✔	Battery	3 (3)	✔	✔	✔	❌
✔	Binary Sensor (deprecated)	2 (2)	✔	✔	✔	❌
✍🏻	Binary Switch	2 (2)	✔	✔	❌	❌
✍🏻	Central Scene	3 (3)	✔	✔	❌	❌
✍🏻	Climate Control Schedule (deprecated)	1 (1)	❌	✔	❌	❌
✔	Clock	1 (1)	✔	✔	✔	❌
✍🏻	Color Switch	3 (3)	✔	✔	❌	❌
✍🏻	Configuration	4 (4)	✔	✔	❌	❌
❌	Controller Replication	- (1)	❌	❌	❌	❌
✔	CRC-16 Encapsulation (deprecated)	1 (1)	✔	✔	✔	❌
❌	Demand Control Plan Configuration	- (1)	❌	❌	❌	❌
❌	Demand Control Plan Monitor	- (1)	❌	❌	❌	❌
✍🏻	Device Reset Locally	1 (1)	✔	✔	❌	❌
✍🏻	Door Lock	4 (4)	✔	✔	❌	❌
✍🏻	Door Lock Logging	1 (1)	✔	✔	❌	❌
✍🏻	Energy Production	1 (1)	✔	✔	❌	❌
✍🏻	Entry Control	1 (1)	✔	✔	❌	❌
✍🏻	Firmware Update Meta Data	7 (8)	✔	✔	✔	❌
❌	Generic Schedule	- (1)	❌	❌	❌	❌
❌	Geographic Location	- (1)	❌	❌	❌	❌
❌	Grouping Name (deprecated)	- (1)	❌	❌	❌	❌
❌	HRV Control	- (1)	❌	❌	❌	❌
❌	HRV Status	- (1)	❌	❌	❌	❌
✍🏻	Humidity Control Mode	1 (2)	✔	✔	❌	❌
✍🏻	Humidity Control Operating State	1 (1)	✔	✔	❌	❌
✍🏻	Humidity Control Setpoint	2 (2)	✔	✔	❌	❌
✍🏻	Inclusion Controller	1 (1)	❌	✔	❌	❌
✍🏻	Indicator	4 (4)	✔	✔	❌	❌
❌	IP Association	- (1)	❌	❌	❌	❌
❌	IR Repeater	- (1)	❌	❌	❌	❌
✍🏻	Irrigation	1 (1)	✔	✔	❌	❌
✔	Language	1 (1)	✔	✔	✔	❌
✍🏻	Lock (deprecated)	1 (1)	✔	✔	❌	❌
❌	Mailbox	- (2)	❌	❌	❌	❌
✔	Manufacturer Specific	2 (2)	✔	✔	✔	❌
✍🏻	Meter	6 (6)	✔	✔	❌	❌
❌	Meter Table Configuration	- (1)	❌	❌	❌	❌
❌	Meter Table Monitor	- (3)	❌	❌	❌	❌
✔	Multi Channel	4 (4)	✔	✔	✔	❌
✔	Multi Channel Association	5 (5)	✔	✔	✔	❌
✔	Multi Command	1 (1)	✔	✔	✔	❌
✔	Multilevel Sensor	11 (11)	✔	✔	✔	❌
✍🏻	Multilevel Switch	4 (4)	✔	✔	❌	❌
❌	Multilevel Toggle Switch (deprecated)	- (1)	❌	❌	❌	❌
❌	Network Management Basic Node	- (2)	❌	❌	❌	❌
❌	Network Management Inclusion	- (4)	❌	❌	❌	❌
❌	Network Management Installation and Maintenance	- (4)	❌	❌	❌	❌
❌	Network Management Proxy	- (4)	❌	❌	❌	❌
✔	No Operation	1 (1)	✔	✔	✔	❌
✍🏻	Node Naming and Location	1 (1)	✔	✔	❌	❌
❌	Node Provisioning	- (1)	❌	❌	❌	❌
✍🏻	Notification	8 (9)	✔	✔	❌	❌
✍🏻	Powerlevel	1 (1)	❌	✔	❌	❌
❌	Prepayment	- (1)	❌	❌	❌	❌
❌	Prepayment Encapsulation	- (1)	❌	❌	❌	❌
✍🏻	Protection	2 (2)	✔	✔	❌	❌
❌	Pulse Meter (deprecated)	- (1)	❌	❌	❌	❌
❌	Rate Table Configuration	- (1)	❌	❌	❌	❌
❌	Rate Table Monitor	- (1)	❌	❌	❌	❌
✍🏻	Scene Activation	1 (1)	✔	✔	❌	❌
✍🏻	Scene Actuator Configuration	1 (1)	✔	✔	❌	❌
✍🏻	Scene Controller Configuration	1 (1)	✔	✔	❌	❌
❌	Schedule	- (4)	❌	❌	❌	❌
✍🏻	Schedule Entry Lock	3 (4)	✔	✔	❌	❌
❌	Screen Attributes	- (2)	❌	❌	❌	❌
❌	Screen Meta Data	- (2)	❌	❌	❌	❌
✔	Security	1 (1)	✔	✔	✔	❌
✍🏻	Security 2	1 (2)	✔	✔	❌	❌
❌	Simple AV Control	- (4)	❌	❌	❌	❌
✍🏻	Sound Switch	2 (2)	✔	✔	❌	❌
✔	Supervision	2 (2)	✔	✔	✔	❌
❌	Tariff Table Configuration	- (1)	❌	❌	❌	❌
❌	Tariff Table Monitor	- (1)	❌	❌	❌	❌
✍🏻	Thermostat Fan Mode	5 (5)	✔	✔	❌	❌
✍🏻	Thermostat Fan State	2 (2)	✔	✔	❌	❌
✍🏻	Thermostat Mode	3 (3)	✔	✔	❌	❌
✔	Thermostat Operating State	2 (2)	✔	✔	✔	❌
✔	Thermostat Setback	1 (1)	✔	✔	✔	❌
✍🏻	Thermostat Setpoint	3 (3)	✔	✔	❌	❌
✔	Time	2 (2)	✔	✔	✔	❌
✍🏻	Time Parameters	1 (1)	✔	✔	❌	❌
✍🏻	Transport Service	2 (2)	❌	❌	❌	❌
✍🏻	User Code	2 (2)	✔	✔	❌	❌
❌	User Credential	- (1)	❌	❌	❌	❌
✔	Version	3 (3)	✔	✔	✔	❌
✍🏻	Wake Up	3 (3)	✔	✔	❌	❌
✍🏻	Window Covering	1 (1)	✔	✔	❌	❌
✔	Z-Wave Plus Info	2 (2)	✔	✔	✔	❌
❌	Z/IP	- (4)	❌	❌	❌	❌
❌	Z/IP 6LoWPAN	- (1)	❌	❌	❌	❌
❌	Z/IP Gateway	- (1)	❌	❌	❌	❌
❌	Z/IP Naming and Location	- (1)	❌	❌	❌	❌
❌	Z/IP ND	- (2)	❌	❌	❌	❌
❌	Z/IP Portal	- (1)	❌	❌	❌	❌
✍🏻	Z-Wave Protocol	1 (1)	❌	❌	❌	❌
✍🏻	Z-Wave Long Range	1 (1)	❌	❌	❌	❌

Add payload validation to all deserialization routines

This avoids crashing when nodes send invalid CCs

Change value events to correctly model map-like properties

ConfigurationCC: Correct interview procedure for V3+ nodes

==> lib/commandclass/ConfigurationCC.ts in scanParametersV3

MultilevelSensorCC: Correct interview procedure

Add an API to read a value from a node's value DB

e.g.

node.getValue({
  commandClass: 4,
  endpoint: 1,
  propertyName: "something",
  propertyKey: 1,
});

[Tracking] Implement `toLogEntry` in all CCs and their subclasses

current implementation status:

All CCs have a toLogEntry implementation :)

WARN no handlers registered during interview

17:33:16.753 CNTRLR » [Node 004] querying manufacturer information...
17:33:16.777 DRIVER     no handlers registered!
17:33:16.794 CNTRLR   [Node 003]   supports CC Z-Wave Plus Info (0x5e) in version 2
17:33:16.795 CNTRLR » [Node 003]   querying the CC version for Version (0x86)...
17:33:16.832 DRIVER     no handlers registered!
17:33:16.847 CNTRLR   [Node 003]   supports CC Version (0x86) in version 2
17:33:16.848 CNTRLR » [Node 003]   querying the CC version for Manufacturer Specific (0x72)...
17:33:16.887 DRIVER     no handlers registered!
17:33:16.898 CNTRLR   [Node 003]   supports CC Manufacturer Specific (0x72) in version 2

Consider moving `supportsCommand` from CC to CCAPI

Investigate invalid messages

0x01090004000303300300c1

Don't crash when a CC is received that cannot be decoded

For example, the Aeon Labs Multisensor sends BasicCC.Set commands.

Handle automatic wrapping of CCs in MultiChannelCCs if they have a non-zero endpoint

MultilevelSensorCC: Requirement to probe sensors

Unless unsolicited Multilevel Sensor Report Commands are received, a controlling node MUST:

Probe the current reading for each supported sensor type at least every 6 hours for listening nodes.
Probe the current reading for each supported sensor type when the supporting node issues a Wake Up Notification Command for sleeping nodes.

Consider solving the strictNullChecks compatibility with subclassing CCs

Currently, we cannot use strictNullChecks in combination with the CC properties as it adds too much noise.
Subclassing the CCs for each command and/or version would help.

Add a way to expect multiple commands in response to a request

Some CCs like ScheduleCC have the ability to split their contents across multiple messages, advertising the reports to follow. We need a way to wait for all of them before resolving the response promises.

Add decorator to mark CC key value pairs

Some CC reports are used to update key value pairs of a property (e.g. multi sensors).
We need a way to mark the corresponding properties, so they can be stored with persistValues

Support extended CommandClasses (16bit ID)

Add a way to keep nodes awake

When repreatedly sending messages outside of the node query, we need a way to not automatically send noMoreInformation.

ConfigurationCC: get V1/V2 parameter scan working

Add a way to send multiple messages in one request

Some CCs like ScheduleCC have the ability to split their contents across multiple messages, advertising the reports to follow. We need a way to handle those and treat them like sending a single command.

Add a way to handle requests that might or might not get a response

e.g. ConfigurationCC.Get for unsupported parameters

Design external API

Rework logging namespaces and loglevels

io contains too much noise and should be split into "debug" and "silly"
controller and driver have no clear separation of concerns

Weiterentwicklung des Adapters

Hallo, hab mir mal deinen Source geladen und ein wenig mit rumgespielt.
Kann schon Temperaturen auf meinen Danfoss setzen.

Jetzt aber die Frage, hast du bereits eine Weiterentwicklung deines Codes oder soll
ich meinen Teil mal sauber und einen Pull Request machen.

LG Christian

List of new logger bugs

(fixed by a4ab873) [ACK] is not printed like a tag

(fixed by b1cf666) receipt of 1-byte messages in particular are logged multiple times:

20:15:03.804 SERIAL « 0x06                                                                 (1 bytes)
20:15:03.805 SERIAL   Buffer := 0x06                                                       (1 bytes)
20:15:03.806 SERIAL « [ACK]                                                                   (0x06)

(fixed by 11c5a59) The send queue should include the message type (Request/Response)

MultiChannel/MultiCommandCC: Correctly detect expected responses

Add more multilevel sensor types

See OpenZWave/open-zwave#1566

Use CC APIs during node interview

Fix and update message class test templates

Related to #63

Test ValueDB and CC serialization for consistency

Currently, the conversion and (de)serialization of map-like values seems inconsistent.

Ideally, the valueDB should either:

internally store map-like values as real maps
or return map-like values as maps when asked to with getValues()

    at ZWaveController.handleAddNodeRequest (C:\Repositories\node-zwave-js\src\lib\controller\Controller.ts:517:7)
    at Driver.handleRequest (C:\Repositories\node-zwave-js\src\lib\driver\Driver.ts:939:33)
    at Driver.handleMessage (C:\Repositories\node-zwave-js\src\lib\driver\Driver.ts:719:15)
    at Driver.serialport_onData (C:\Repositories\node-zwave-js\src\lib\driver\Driver.ts:596:24)