Hi,
does anybody set their FHT80b’s time using the FHT binding? This is configured in openhab.cfg via
fht:time.update=true // update time ...
fht:time.update.cron=0 0 4 * * ? // ... at night
The log shows that commands are being sent (to my nanoCUL). However, the time on my FHT80b devices does not change.
Did anybody have this (or a similar) issue?
Cheers
ub
Hi @ugh_bough,
i tried using the set time configuration with my nanoCUL and openhab2.
It leads to a situation where my CUL isn’t working anymore. I have to reboot in order to make it work again.
Normally sending commands to my my FHT80’s and FS20 devices is working well.
Stacktrace:
2017-02-03 19:35:01.531 [ERROR] [port.cul.internal.AbstractCULHandler] - Can't write to CUL /dev/ttyACM0
java.io.IOException: Input/output error in writeArray
at gnu.io.RXTXPort.writeArray(Native Method)
at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1211)[223:com.neuronrobotics.nrjavaserial:3.12.0.OH]
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)[:1.8.0]
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)[:1.8.0]
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)[:1.8.0]
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)[:1.8.0]
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)[:1.8.0]
at java.io.BufferedWriter.flush(BufferedWriter.java:254)[:1.8.0]
at org.openhab.io.transport.cul.internal.AbstractCULHandler.writeMessage(AbstractCULHandler.java:306)[220:org.openhab.io.transport.cul:1.9.0.201701020211]
at org.openhab.io.transport.cul.internal.AbstractCULHandler.access$0(AbstractCULHandler.java:297)[220:org.openhab.io.transport.cul:1.9.0.201701020211]
at org.openhab.io.transport.cul.internal.AbstractCULHandler$SendThread.run(AbstractCULHandler.java:59)[220:org.openhab.io.transport.cul:1.9.0.201701020211]
2017-02-03 19:35:01.684 [ERROR] [port.cul.internal.AbstractCULHandler] - Can't write report command to CUL
java.io.IOException: Input/output error in writeArray
at gnu.io.RXTXPort.writeArray(Native Method)
at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1211)[223:com.neuronrobotics.nrjavaserial:3.12.0.OH]
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)[:1.8.0]
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)[:1.8.0]
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)[:1.8.0]
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)[:1.8.0]
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)[:1.8.0]
at java.io.BufferedWriter.flush(BufferedWriter.java:254)[:1.8.0]
at org.openhab.io.transport.cul.internal.AbstractCULHandler.requestCreditReport(AbstractCULHandler.java:285)[220:org.openhab.io.transport.cul:1.9.0.201701020211]
at org.openhab.io.transport.cul.internal.AbstractCULHandler.writeMessage(AbstractCULHandler.java:311)[220:org.openhab.io.transport.cul:1.9.0.201701020211]
at org.openhab.io.transport.cul.internal.AbstractCULHandler.access$0(AbstractCULHandler.java:297)[220:org.openhab.io.transport.cul:1.9.0.201701020211]
at org.openhab.io.transport.cul.internal.AbstractCULHandler$SendThread.run(AbstractCULHandler.java:59)[220:org.openhab.io.transport.cul:1.9.0.201701020211]
Anyone got a hint on this?
Edit:
When i shutdown my openhab i get this exception in my log too:
2017-02-04 20:55:00.154 [ERROR] [org.quartz.core.JobRunShell ] - Job cul.FHT UpdateFHTTimeJob threw an unhandled Exception:
java.lang.NullPointerException
at org.openhab.binding.fht.internal.FHTBinding.writeRegisters(FHTBinding.java:597)[216:org.openhab.binding.fht:1.9.0.201701020211]
at org.openhab.binding.fht.internal.FHTBinding.updateTime(FHTBinding.java:553)[216:org.openhab.binding.fht:1.9.0.201701020211]
at org.openhab.binding.fht.internal.FHTBinding.access$1(FHTBinding.java:549)[216:org.openhab.binding.fht:1.9.0.201701020211]
at org.openhab.binding.fht.internal.FHTBinding$UpdateFHTTimeJob.execute(FHTBinding.java:620)[216:org.openhab.binding.fht:1.9.0.201701020211]
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)[104:org.eclipse.smarthome.core.scheduler:0.9.0.b3]
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)[104:org.eclipse.smarthome.core.scheduler:0.9.0.b3]
2017-02-04 20:55:00.189 [ERROR] [org.quartz.core.ErrorLogger ] - Job (cul.FHT UpdateFHTTimeJob threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: java.lang.NullPointerException]
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)[104:org.eclipse.smarthome.core.scheduler:0.9.0.b3]
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)[104:org.eclipse.smarthome.core.scheduler:0.9.0.b3]
Caused by: java.lang.NullPointerException
at org.openhab.binding.fht.internal.FHTBinding.writeRegisters(FHTBinding.java:597)[216:org.openhab.binding.fht:1.9.0.201701020211]
at org.openhab.binding.fht.internal.FHTBinding.updateTime(FHTBinding.java:553)[216:org.openhab.binding.fht:1.9.0.201701020211]
at org.openhab.binding.fht.internal.FHTBinding.access$1(FHTBinding.java:549)[216:org.openhab.binding.fht:1.9.0.201701020211]
at org.openhab.binding.fht.internal.FHTBinding$UpdateFHTTimeJob.execute(FHTBinding.java:620)[216:org.openhab.binding.fht:1.9.0.201701020211]
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)[104:org.eclipse.smarthome.core.scheduler:0.9.0.b3]
... 1 more
Hi,
I have fixed my initial bug (incorrect commands were sent to culfw).
The according pull request was accepted and also incorporated into the 1.9 branch, see https://github.com/openhab/openhab1-addons/pull/5070.
Can you get a nightly build of the fht-1.9 addon (I’m not sure that there is one) and test again?
Cheers
ugh_bough
I took the artifact from https://openhab.ci.cloudbees.com/job/openHAB1-Addons/1420/org.openhab.binding$org.openhab.binding.fht/ (1.10.SNAPSHOT).
CUL Binding does not crash anymore 
However, it seems that you changes lead to a unkown command:
22:31:06.996 [WARN ] [nhab.binding.fht.internal.FHTBinding] - Received unknown FHT command:
22:31:07.274 [WARN ] [nhab.binding.fht.internal.FHTBinding] - Received unknown FHT command:
22:31:07.551 [WARN ] [nhab.binding.fht.internal.FHTBinding] - Received unknown FHT command:
22:31:07.828 [WARN ] [nhab.binding.fht.internal.FHTBinding] - Received unknown FHT command:
22:31:08.103 [WARN ] [nhab.binding.fht.internal.FHTBinding] - Received unknown FHT command:
The times aren’t updated on my FHT80b devices.
Regards,
Matthew
Hi Matthias,
thanks for having a look.
I cannot find similar log entries in my setup. Also times are updated correctly on my FHT80b devices.
My changes were trivial: I replaced a leading ‘F’ in the control messages generated by the FHT binding to a leading ‘T’ – according to the spec of the CUL firmware, see culfw.de/commandref.html.
// F-messages are for FS20 devices, T-messages for FHT devices
What culfw version are you running? Current is 1.66.
Regards
BB
Hi @ugh_bough,
good point, my firmware is kinda old:
V 1.55 CUL868 (never change a running system)
However, i’ll try updating firmeware and check again if Time-Update is working.
Regards,
Matthew
If you discover anything that ought to be documented in the binding’s README.md (such as needing above a certain firmware level), please submit a pull request so others will know, too! Thanks.
sadly upgrading to the newest firmware 1.66 does not change anything.
still got the “unkown command” errors.
looking at the sourcecode the line where the error is happening looks strange to me:
Isn’t this a method that is called when data is received ? not when data is sent?
however, the logging is wrong here. both strings should be concatenated.
when the time update is sent there is no logging right?
Hi,
the time update related code is located in lines 513-630 (in the same file), where there is really only error logging happening. Hence no logging for me.
My log looks like this (other debug noise removed):
04:35:00.282 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:312 ] - Sending raw message to CUL /dev/ttyUSB0: 'T442564236304620c61026011
04:36:52.377 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: T442500A62BFE
04:36:53.566 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: T4425646925FE
04:36:53.838 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: T4425636904FE
04:36:54.110 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: T442562690CFE
04:36:54.381 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: T4425616902FF
04:36:55.126 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: T4425606911FF
04:38:48.146 [DEBUG] [o.o.i.t.c.i.AbstractCULHandler:239 ] - Received raw message from CUL: T442500A62BFE
As you can see, all registers written in the time update command (T4425 64 23 63 04 62 0c 61 02 60 11) are reported back from the FHT80b (fenced in 00A62BFE-messages).
Maybe these are the unknown messages in your setup? After all, there are five registers and your log shows five unknown messages, plus both your and my messages arrive in similar time offsets.
Cheers
bb
PS This might be a stupid question, however, often enough the root cause of a problem is trivial. You are using FHT80 b devices which are able to receive commands from your nanoCUL, right? 
not a stupid question in order to be sure there’s no hardware issue.
i got several FHT80b-2 and FHT80b-3 devices and sending desired temperature works for all of them.
after activating debug log for AbstractCULHandler i see the following log statements but no errors or received messages afterwards:
2017-02-12 10:20:00.091 [DEBUG] [port.cul.internal.AbstractCULHandler] - Sending raw message to CUL /dev/ttyACM1: 'T17266414630a620c61026011'
...
2017-02-12 10:25:00.084 [DEBUG] [port.cul.internal.AbstractCULHandler] - Sending raw message to CUL /dev/ttyACM1: 'T0D276419630a620c61026011'
the times are updated for all FHT80s all 5 minutes right? I’ll wait until all my 7 devices were sent commands to and report back here.
Hi,
the FHT binding starts updating times according to the config
fht:time.update.cron=0 0 4 * * ? // example time at night
in openhab.cfg. I.e. at this point in time will a time update command be sent to the “first” of your devices (no specific ordering noticeable, for me).
Then, using offsets of 5 minutes the binding sends time update commands to the other registered FHT80bs. I have six devices, so updating all their times takes ~30m.
Notes:
Regards
bb
Hi @ugh_bough,
its working for me right now. All my devices received the time update.
Don’t know where the problem was lying 
Now trying to figure out since which firmware it should work.
Definiately not working with 1.55. Working with for me with 1.66.
So i’m looking for any FHT related changes noted in http://culfw.de/CHANGED:
Maybe its working since the timeout change in V1.56?
However, the documentation (README.MD) of the FHT Binding to my mind is wrong and needs to be fully reworked.
Maybe i’ll give it a try next weekend and include our findings of this thread there.
Please submit a pull request to change this file which will be reflected here after merge. Please use the existing header names and levels, adding any new headers around the existing (for the sake of consistency with all other add-ons). After the intro paragraph (which must appear on a single line), consider adding a new
## Prerequisites
heading that clearly describes needed firmware levels and any other preconditions needed for the binding to work.
So many unnecessary problems can so easily be solved before they even happen thanks to good documentation.
Thank you!
Hi,
I’m afraid that this problem cannot be so easily resolved.
The required firmware “culfw” will not only enable said “nanoCUL” devices to control the heating, but it can also be used with various so called CUN, CUL, CUNO, etc. devices.
Which version of culfw works with the various devices (and their respective versions) can most likely be answered only incompletely by guys owning a nanoCUL device only 
Regarding nanoCUL. The culfw svn repo contains a folder called “Devices/nanoCUL” for tag 1.66 but not for tag 1.61.
I think I have seen references to culfw versions between 1.66 and 1.61, i.e. at first glance it seems undocumented since when nanoCUL is included in the firmware.
Moreover, for Matthias, nanoCUL could set temperatures even with culfw 1.55 despite the fact that there is no nanoCUL specific folder in this tag.
TL;DR It is unclear since when nanoCUL is officially supported by culfw and hence by the FHT binding. Similar for other devices like CUL, CUN, etc.
Regards
bb
Hi @ugh_bough,
i was wrong stating that i’m using a nanoCUL for FHT. I got confused by my recent HomeMatic Setup for which i built a nanoCUL.
For FHT/FS20 i’m using CUL3.
I’m with you that we cannot describe all specific prerequisites, however note our findings.
And - more important - provide at least some documentation for the binding itself.
Note: I still got errors after some time (i assume due to the “spamming” of time updates):
(LOVF) Limit Overflow: Last message lost. You are using more than 1% transmitting time. Reduce the number of rf messages
I’m currently reinstalling a clean setup on my new RPi3, if the error persists i’ll revert to old firmeware without Limitoverflow (or disabling time update)…
Regards,
Matthias
Hi @Matthew,
Have a look at https://forum.fhem.de/index.php?topic=9997.0 and at the MAX_CREDIT definition in file culfw/clib/rf_send.h. Maybe you can resolve your problem by increasing the value of MAX_CREDIT?
Regards
bb