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

View Code? Open in Web Editor NEW

731.0 24.0 585.0 97.84 MB

Z-Wave driver written entirely in JavaScript/TypeScript

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

License: MIT License

TypeScript 99.40% JavaScript 0.45% Batchfile 0.01% Shell 0.12% PEG.js 0.03%

z-wave zwave iot smart-home wireless razberry hacktoberfest

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

ConfigurationCC: Correct interview procedure for V3+ nodes

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

Update message class templates to use inheritance

Make sure every CCCommand has a deserialization branch

even if it is not implemented

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)

Add a way to target a specific endpoint with the CCAPI

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

MultilevelSensorCC: Correct interview procedure

Consider moving `supportsCommand` from CC to CCAPI

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

Add payload validation to all deserialization routines

This avoids crashing when nodes send invalid CCs

Add a unified driver mock that works in all tests

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

Add a way to store map-like CC values

CCs like BinarySensorCCReport are to be interpreted like key-value pairs of a map. The contents of multiple BinarySensorCCReports belong together, so we should store them together.

Investigate invalid messages

0x01090004000303300300c1

Finish Configuration CC

Add more multilevel sensor types

See OpenZWave/open-zwave#1566

ConfigurationCC: get V1/V2 parameter scan working

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

e.g. ConfigurationCC.Get for unsupported parameters

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()

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

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 :)

Crash: UnhandledPromiseRejectionWarning: Error: The inclusion could not be started.

    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)

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.

Invert the log colors for tags

Design external API

Fix and update message class test templates

Related to #63

Support extended CommandClasses (16bit ID)

Improve logging (like OpenHAB does it)

[Tracking] Implementation status of Command Classes

	CC name	Version	Interview?	API?	setValue?	pollValue?
✔	Alarm Sensor (deprecated)	1 (1)	✔	✔	✔	❌
❌	Alarm Silence	- (1)	❌	❌	❌	❌
❌	Anti-Theft	- (3)	❌	❌	❌	❌
❌	Application Status	- (1)	❌	❌	❌	❌
✔	Association	3 (3)	✔	✔	✔	❌
❌	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)	✔	✔	❌	❌
✍🏻	Climate Control Schedule (deprecated)	1 (1)	❌	✔	❌	❌
✍🏻	Central Scene	3 (3)	✔	✔	❌	❌
✔	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 (7)	✔	✔	✔	❌
❌	Generic Schedule	- (1)	❌	❌	❌	❌
❌	Geographic Location	- (1)	❌	❌	❌	❌
❌	Grouping Name (deprecated)	- (1)	❌	❌	❌	❌
❌	HRV Status	- (1)	❌	❌	❌	❌
❌	HRV Control	- (1)	❌	❌	❌	❌
✍🏻	Humidity Control Mode	2 (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 Proprietary	1 (1)	✔	✔	❌	❌
✔	Manufacturer Specific	2 (2)	✔	✔	✔	❌
✍🏻	Meter	6 (6)	✔	✔	❌	❌
❌	Meter Table Configuration	- (1)	❌	❌	❌	❌
❌	Meter Table Monitor	- (3)	❌	❌	❌	❌
❌	Meter Table Push Configuration	- (1)	❌	❌	❌	❌
✔	Multi Channel	4 (4)	✔	✔	✔	❌
✔	Multi Channel Association	4 (4)	✔	✔	✔	❌
✔	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	- (3)	❌	❌	❌	❌
❌	Network Management Installation and Maintenance	- (2)	❌	❌	❌	❌
❌	Network Management Proxy	- (3)	❌	❌	❌	❌
✔	No Operation	1 (1)	✔	✔	✔	❌
✍🏻	Node Naming and Location	1 (1)	✔	✔	❌	❌
❌	Node Provisioning	- (1)	❌	❌	❌	❌
✍🏻	Notification	8 (8)	✔	✔	❌	❌
✍🏻	Powerlevel	1 (1)	❌	✔	❌	❌
❌	Prepayment	- (1)	❌	❌	❌	❌
❌	Prepayment Encapsulation	- (1)	❌	❌	❌	❌
❌	Proprietary (deprecated)	- (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 (deprecated)	3 (3)	✔	✔	❌	❌
❌	Screen Attributes	- (2)	❌	❌	❌	❌
❌	Screen Meta Data	- (2)	❌	❌	❌	❌
✔	Security	1 (1)	✔	✔	✔	❌
✍🏻	Security 2	1 (1)	✔	✔	❌	❌
❌	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)	✔	✔	❌	❌
✔	Version	3 (3)	✔	✔	✔	❌
✍🏻	Wake Up	3 (3)	✔	✔	❌	❌
✍🏻	Window Covering	1 (1)	✔	✔	❌	❌
❌	Z/IP	- (4)	❌	❌	❌	❌
❌	Z/IP 6LoWPAN	- (1)	❌	❌	❌	❌
❌	Z/IP Gateway	- (1)	❌	❌	❌	❌
❌	Z/IP Naming and Location	- (1)	❌	❌	❌	❌
❌	Z/IP ND	- (1)	❌	❌	❌	❌
❌	Z/IP Portal	- (1)	❌	❌	❌	❌
✔	Z-Wave Plus Info	2 (2)	✔	✔	✔	❌

Add a way to translate numeric property keys to speaking names

As of #70 we now have property keys in the value DB. It is preferable to store the raw numeric keys, but for applications we need to expose speaking names for them.

Handle dead nodes that return to life

especially during the interview process

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.

Invalid argument for registerRequestHandler

https://github.com/AlCalzone/node-zwave-js/blob/e975db07bf5e6eefe53a3144b3dfb8bc4e4398e6/src/lib/controller/Controller.ts#L94

The handlers are supposed to return a boolean, but the passed handler returns a Promise!

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.

MultiChannel/MultiCommandCC: Correctly detect expected responses

Refactor ZWaveLibraryTypes into its own file

It is currently shared by VersionCC and GetControllerVersionResponse

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

Add @expectedCC to CentralSceneCC commands

https://github.com/AlCalzone/node-zwave-js/blob/82f57733095abee0b6b77825b945588a34214842/src/lib/commandclass/CentralSceneCC.ts#L37

ValueDB logs don't include the node number

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

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

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

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()