search

ioBroker / ioBroker.maxcul

Control max! devices over CUL stick
Other
4 stars 8 forks source link

Update to Serialport 7.1.5 #25

Closed bowao closed 5 years ago

Apollon77 commented 5 years ago

Cool. You verified it that it is working?

bowao commented 5 years ago

Actually, yes, but unfortunately I had to realize that I made a little mistake. Fix is on the way. Works fine with me since then.

bowao commented 5 years ago

I had found isOpen functions in "main.js" und fixed it. But please wait with merge. I noticed an unusual behavior: Sometimes, after the adapter works for up to 2 hours without error, no more packets will be sent from the CUL. No error message except "Packet ...... sent but no response!". I will continue to investigate further and report.

Apollon77 commented 5 years ago

Thank you very much! I will wait with merge till your approval

bowao commented 5 years ago

I'm not sure if the first and the last fix is necessary or a system-reboot did the job. But with this final code it worked for me non stop more than 38 hours without any problems or errors.

Apollon77 commented 5 years ago

ok, cool, will merge tonight and release to latest. Big thank you!

GermanBluefox commented 5 years ago

Any news here?

Apollon77 commented 5 years ago

needs merge and release new version to npm ... I would give it to forum to try ... will try to do tomorrow ... or you if you are faster and have time :-)

bowao commented 5 years ago

Since the update to serialport 7.1.5 the adapter does not crash any more but gets stuck instead if errors occur outside the communicationLayer.js. Before, with the old serialport version 4.0.7, the whole adapter crashed and restarted immediately. To handle errors that may arise in the further processing of the received messages, I have implemented try/catch blocks in these calls. I also fix an "uncaught exception: this[packet.getCommand(...)] is not a function" error. See Issue#23 from MubiTec. It occurs in the rare case that wrong scrambled messages are sent from CUL and the command "PairPong" is recognized by the adapter. e.g. message: incoming raw data from CUL: Z1D5600011A002081930C2D8181002081930C2C8A11010202141D1234560001 To catch this error, I have implemented the missing "PairPong" function. Furthermore, there can be as well incomplete messages which have no or wrong sized payload. e.g. message : incoming raw data from CUL: Z0A0E01020214073F12345600 So I have modified the message.split and implemented requests which refuse all messages without or with wrong sized payload. Such wrong messages appear very rare in my set up, sometimes once a day, sometimes not at all for several days. I'm sure that these messages are sent like this from CUL, as the length of the message always corresponds to the checksum included in the message. I don't know why it is sent in this way from the CUL. But this is - in my opinion - a hardware problem and no mistake from the maxcul-adapter.

Apollon77 commented 5 years ago

Thank you. I will have a deeper look too next week when back from Vacation.

bowao commented 5 years ago

Fixed some minor issues:

Increased the valid payload minimum length for pairing, to prevent creating ghost devices in case of receiving wrong scrambled messages from CUL (See Issue#23). Fix issue in Poll-Timeout in case of vacation mode. Prevents the log message 'Packet ... sent but no response!' after sending time information (checkTimeIntervallFired) Set time and date values to Acknowledged after sending day profile

Btw I reassembled my nanoCUL on a circuit board (instead of oxidizing on a breadboard like the past 2 years). But it still sends rarely these wrong scrambled messages. I'm still convinced that this is a (nano)CUL issue or an edge of communication range problem. Anyway, the maxcul-adapter is able to handle it now.

Apollon77 commented 5 years ago

I was just about to check it :-) Should I wait some more time?

Apollon77 commented 5 years ago

Ok, I will check later today and accept and release to latest with a forum test thread

bowao commented 5 years ago

No. It is OK. If I notice something else I'll do a new pull request ;)

Apollon77 commented 5 years ago

Would you be sos kind and provide a change log for the changes in the README. Simply add a new minor version to the changelog list. I will then take care about the rest. I would be with:

Apollon77 commented 5 years ago

@bowao Thank you! I merged,

Would you be so kind and have a look at https://github.com/ioBroker/ioBroker.maxcul/pull/11/files ... I would also merge that if you think it makes sense ... you have more insight then me at the moment

Apollon77 commented 5 years ago

@bowao I prepared the rst for 1.1.0 and also updated some dependencies. COuld you please have a final Check (install from Github) that nothing of those deps broke something? Thank you!

bowao commented 5 years ago

Regarding the pull request #11 I have never noticed this behavior in my setup, but I tested it.

I made renewals of my pairing with one of my shutter contacts in different starting points as follows:

  1. Without deleting it from iobroker and without device reset.
  2. Without deleting it from iobroker but doing a device reset
  3. Deleting it from iobroker but without device reset.
  4. Deleting it from iobroker and do a device reset.

In all cases the shutter contact was created with src and serial correctly and messages from device were received without any problems.

The only way to generate the described behavior, was if the device was never paired with the maxcul-adapter. (Pair Button on device never pressed) In this case the device was named by src when the CUL received a normal state message. But this is in my opinion a normal behavior, because there is no serial in the state message.

Therefore, I can not recommend merging pull request #11!

But in one thing he was right:

The shutter contact is named wrong in the ,,createShutterContact function" ("Push Button" instead of "Shutter Contact").

And I have seen another minor issue in this part of code:

In case of receiving a message from an unknown shutter contact device, the function createButton is called instead of createShutterContact.

But imho these are minor issues.

Apollon77 commented 5 years ago

Thank you for your review, I will copy it in the other PR ...

Apollon77 commented 5 years ago

1.1.0 published on npm, will be in latest tomorrow

bowao commented 5 years ago

Here are my results from the github installation:

I deleted the old Version and made a new Installation from github. I had a little right-issues with my iobroker installation and must run the installation-fixer first. Maybe there is more to do but for now it works.

The maxcul-adapter seems to be OK. I can pair devices and receive messages.

Log Install from github:

$ ./iobroker url "https://github.com/ioBroker/ioBroker.maxcul/tarball/master" maxcul --debug
install https://github.com/ioBroker/ioBroker.maxcul/tarball/master
npm install https://github.com/ioBroker/ioBroker.maxcul/tarball/master --production --save --prefix "/opt/iobroker" (System call)
+ iobroker.maxcul@1.1.0added 1 package from 1 contributor and audited 2030 packages in 37.372s

found 54 vulnerabilities (38 low, 16 high)  run `npm audit fix` to fix them, or `npm audit` for details

got /opt/iobroker/node_modules/iobroker.maxcul/admin
upload [3] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/words.js words.js application/javascript
upload [2] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/maxcul.png maxcul.png image/png
upload [1] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/index_m.html index_m.html text/html
upload [0] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/index.html index.html text/html
process exited with code 0

Log add instance:

$ ./iobroker add maxcul  --host xarypi3
host.xarypi3 install adapter maxcul
npm install --production (System call) in "/opt/iobroker/node_modules/iobroker.maxcul"
npm WARN deprecated gulp-util@3.0.8: gulp-util is deprecated - replace it, following the guidelines at https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5
npm WARN deprecated graceful-fs@3.0.11: please upgrade to graceful-fs 4 for compatibility with current and future versions of Node.js
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated natives@1.1.6: This module relies on Node.js's internals and will break at some point. Do not use it, and update to graceful-fs@4.x.
npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated graceful-fs@1.2.3: please upgrade to graceful-fs 4 for compatibility with current and future versions of Node.js
prebuild-install
WARN install No prebuilt binaries found (target=8.16.0 runtime=node arch=arm libc= platform=linux)
npm notice created a lockfile as package-lock.json. You should commit this file.
got /opt/iobroker/node_modules/iobroker.maxcul/admin
upload [3] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/words.js words.js application/javascript
upload [2] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/maxcul.png maxcul.png image/png
upload [1] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/index_m.html index_m.html text/html
upload [0] maxcul.admin /opt/iobroker/node_modules/iobroker.maxcul/admin/index.html index.html text/html
host.xarypi3 object system.adapter.maxcul created
host.xarypi3 create instance maxcul
host.xarypi3 object maxcul.0.info.version created
host.xarypi3 object maxcul.0.info.quota created
host.xarypi3 object maxcul.0.info.limitOverflow created
host.xarypi3 object maxcul.0.info.connection created
host.xarypi3 object maxcul.0.info created
host.xarypi3 object system.adapter.maxcul.0.outputCount created
host.xarypi3 object system.adapter.maxcul.0.inputCount created
host.xarypi3 object system.adapter.maxcul.0.uptime created
host.xarypi3 object system.adapter.maxcul.0.memRss created
host.xarypi3 object system.adapter.maxcul.0.memHeapTotal created
host.xarypi3 object system.adapter.maxcul.0.memHeapUsed created
host.xarypi3 object system.adapter.maxcul.0.cputime created
host.xarypi3 object system.adapter.maxcul.0.cpu created
host.xarypi3 object system.adapter.maxcul.0.connected created
host.xarypi3 object system.adapter.maxcul.0.alive created
host.xarypi3 object system.adapter.maxcul.0 created
process exited with code 0

Log starting adapter:

2019-07-05 18:41:40.676 - info: maxcul.0 starting. Version 1.1.0 in /opt/iobroker/node_modules/iobroker.maxcul, node: v8.16.0
2019-07-05 18:41:41.152 - info: maxcul.0 using serial device /dev/ttyUSB-CUL@38400
2019-07-05 18:41:41.200 - info: maxcul.0 serialPort /dev/ttyUSB-CUL is open!
2019-07-05 18:41:43.206 - debug: maxcul.0 check CUL Firmware version
2019-07-05 18:41:43.222 - debug: maxcul.0 Requested CUL Version...
2019-07-05 18:41:43.238 - debug: maxcul.0 incoming raw data from CUL: V 1.67_nocredits nanoCUL868
2019-07-05 18:41:43.242 - info: maxcul.0 CUL FW Version: V 1.67_nocredits nanoCUL868
2019-07-05 18:41:46.183 - debug: maxcul.0 Send Packet to CUL: X, awaiting drain event
2019-07-05 18:41:46.189 - debug: maxcul.0 serial port buffer have been drained
2019-07-05 18:41:46.191 - debug: maxcul.0 delayed next send by 0ms (Queue length left = 0, Current Credit = 0)
2019-07-05 18:41:47.226 - debug: maxcul.0 enable MAX! Mode of the CUL868
2019-07-05 18:41:47.231 - debug: maxcul.0 X20 written
2019-07-05 18:41:47.235 - debug: maxcul.0 X20 drained
2019-07-05 18:41:47.240 - debug: maxcul.0 Zr written
2019-07-05 18:41:47.244 - debug: maxcul.0 Zr drained
2019-07-05 18:41:47.253 - debug: maxcul.0 Za written
2019-07-05 18:41:47.257 - debug: maxcul.0 Za drained
2019-07-05 18:41:51.188 - debug: maxcul.0 Send Packet to CUL: X, awaiting drain event
2019-07-05 18:41:51.190 - debug: maxcul.0 serial port buffer have been drained
2019-07-05 18:41:51.192 - debug: maxcul.0 delayed next send by 0ms (Queue length left = 0, Current Credit = 900)
....
Apollon77 commented 5 years ago

thank you, I also started Forum thread for release: https://forum.iobroker.net/topic/23638/maxcul-1-1-0-mit-node10-support-und-mehr