FHT8v and CUNO

[Alex van Hoboken]

To control the FHT8v directly from the CUL device I followed the
instructions from the wiki article. To start I have an CUNO v1 with
firmware v1.40 and a FHT8v-2. I'm able to pair the valve with the CUNO
but after that it doesn't respond to the instruction to open the valve
for x%.
After that I upgraded the firmware to v1.44 and repeated the previous
steps. Pairing is no problem but after that it reacts to nothing.
What am I doing wrong? Is there some way to troubleshoot this?

Thanks for any advice,
Alex

[Rudolf Koenig]

> To start I have an CUNO v1 with firmware v1.40 and a FHT8v-2. I'm able to
> pair the valve with the CUNO but after that it doesn't respond to the
> instruction to open the valve for x%.

This looks like a culfw timing problem for me, and it might be that the
IR-Support of the CUNO is responsible for that.

Debugging is only for an expert, or a novice willing to become one. I am in the
lucky position, that I do not have a CUNO so I cannot help :)

To debug it I would enable msec logging in fhem, switch on the CUL FHT protocol
reporting (X67), and check if the CUNO sends the messages exactly in the
115+0.5*x sec rhytm, where x is the last 3 bits of the CUL-FHTID (T01)
If the rhytm is not correct, you might check if my IR-theory is correct by
disabling it in culfw.

[Jelle Kalf]

To my knowledge and the last <and only> update I've done to the CUNOv1 firmware tree didn't include enabling IR. it should still be disabled.

Verstuurd vanaf mijn iPhone

> --
> To unsubscribe from this group, send email to
> fhem-users+...@googlegroups.com

[Alex van Hoboken]

I'm definitely a novice user but I'm not afraid of trying new
things :)
Before I change anything on my CUNO I've looked up the current value
for data reporting and it shows 00 900.
Does that confirm the comments of Jelle that IR is disabled and does
that mean that the problem I have comes from something else?

> > fhem-users+...@googlegroups.com- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

[Rudolf Koenig]

> Before I change anything on my CUNO I've looked up the current value

> that mean that the problem I have comes from something else?

> for data reporting and it shows 00 900.

That means that RF Reception is off (00), and you are not sending much data on
SlowRF (900). This is probably ok for the FHT8v, but I've only tested the 8v
with RF on.

[Alex van Hoboken]

I've tested a few things with the following result:
1) following the procedure from the culfw site I started with a)
setting housecode to 1234, set first valve to 6% and paired the FHT8v.
So far everything ok, the valve paired and after a short while the
first command was received and valve was opened at 6%.
2) subsequent commands (T123400A630) to open the valve are ignored.
Buffer T10 is 00:A630 and stays that way (until I execute another
command offcourse)
3) I've enabled RF debug (X67) and see a lot of fht messages. I see
also the commands for setting the valve and the time between them is
approx. 118s (T123400A630FA). No change on the valve.

What can I do for further troubleshooting and correcting this problem?

[Rudolf Koenig]

> What can I do for further troubleshooting and correcting this problem?

Follow my instructions from above: enable mseclog in fhem, and check if the
interval is exactly 115+0.5*(lower-3-bit-of-your-FHTID)

[Alex van Hoboken]

I enabled mseclog in the global parameters but what appears in the
logfile is probably not enough. First this is what I did:
1) I enabled mseclog and set verbose to 5
2) Turn of fhem, telnet to my CUNO and pairing the FHT8v directly with
my CUNO with house code 1234. result ok.
3) Turned on fhem and within fhem defined the valve with 'define wz
FHT8V 1234'. The fields Type, xmit are filled (type=fht8v, xmit=1234),
status is unknown.
2011.12.29 12:02:01.868 4: HTTP FHEMWEB:192.168.0.101:51186 GET /fhem?
room=+Plots&cmd=define+wz+FHT8V+1234
2011.12.29 12:02:01.868 5: Cmd: >define wz FHT8V 1234<

4) I set the valve to 10% with the command 'set wz valve 10'. The
value for wz valve within FHEM shows now 3% (why not 10%?), and in the
logfile I see only once a reference to this command. I waited
25minutes now and still no other lines in my logfile related to this
valve.
2011.12.29 12:11:30.274 2: FHT8V wz: v: 10
2011.12.29 12:11:30.274 5: CUNO1 sending T123401260A
2011.12.29 12:11:30.274 5: SW: T123401260A
2011.12.29 12:11:30.276 5: Triggering wz (1 changes)
2011.12.29 12:11:30.276 5: wz trigger: Checking CUL_WS_1log for notify
....
2011.12.29 12:11:30.284 4: /fhem?room=Unsorted&cmd=set+wz+valve+10 /
RL: 1228 / text/html; charset=UTF-8 / Content-Encoding: gzip

The valve itself doesn't react within minutes to these commands. The
antenna lights up permanent although I see it blinking sometimes. And
sometimes out of nowhere it does change the valve % but to a
percentage I never entered and the time between my last change in fhem
and the valve changing % can easily be 30 minutes or hours and nothing
is showing up in the logfile.

5) If I try the commands "get wz valve" and set wz pair" fhem returns
an error ('No get implemented for wz'). Why is this not working?

So I probably do something wrong with troubleshooting this but I can't
figure out what. So what to do next to get this thing working?

(my valve is a Conrad FHT 8V-2 / RX868-3V)

Thanks
Alex

[Rudolf Koenig]

> I enabled mseclog in the global parameters but what appears in the
> logfile is probably not enough. First this is what I did:

More detailed instruction:

% telnet fhemhost 7072 # using a unix-compatible telnet program)
fhem> attr global mseclog # enable millisecond logging
fhem> inform timer # enable event reporting in the telnet
fhem> set CUL raw X67 # enable FHT reporting on the CUL
fhem> set wz valve 10 # issue the 8v command
fhem> get CUL raw T10 # verify the 8v buffer in the CUL
fhem> get CUL raw T11 # get the time in seconds/hex until the next
# 8v message is sent. You may repeat this for your
# own plesure until it gets 0

When the T11 timer reaches 0, the CUL sends an 8v message. The 8v antenna
symbol should be now on for a short time.

Verify that the time difference between two 8v messages is exactly
115 + 0.5 * (1234 & 7) == 117

[Alex van Hoboken]

I followed your instructions and this is the result:
1) at timer = 0 the message "Global global UNDEFINED FHT_1234 FHT
1234" appears.
2) This message is repeated approx. every 118s. The exact values are:
118.203 s
117.978 s
118.165 s
118.180 s
118.189 s

This is one second more than the 117 you describe. Is that causing
the problem? How can I solve that? And what does this message mean, do
I have to define anything else besides the "define wz FHT8V 1234"?

Thanks,
Alex

[Alex van Hoboken]

This is what appears in the logfile:
2011.12.29 20:25:12.795 2: FHT8V wz: v: 10
2011.12.29 20:25:55.119 3: FHT Unknown device 1234, please define it
2011.12.29 20:25:55.121 2: autocreate: define FHT_1234 FHT 1234
2011.12.29 20:25:55.122 1: FHT_1234: CODE collides with the FHTID of
the corresponding CUL
2011.12.29 20:25:55.122 1: define: FHT_1234: CODE collides with the
FHTID of the corresponding CUL
2011.12.29 20:25:55.122 1: ERROR: FHT_1234: CODE collides with the
FHTID of the corresponding CUL
...
2011.12.29 20:27:53.322 3: FHT Unknown device 1234, please define it
2011.12.29 20:27:53.324 2: autocreate: define FHT_1234 FHT 1234
2011.12.29 20:27:53.324 1: FHT_1234: CODE collides with the FHTID of
the corresponding CUL
2011.12.29 20:27:53.325 1: define: FHT_1234: CODE collides with the
FHTID of the corresponding CUL
2011.12.29 20:27:53.325 1: ERROR: FHT_1234: CODE collides with the
FHTID of the corresponding CUL

> > 115 + 0.5 * (1234 & 7) == 117- Tekst uit oorspronkelijk bericht niet weergeven -

[Rudolf Koenig]

> This is one second more than the 117 you describe. Is that causing
> the problem?

This is my theory.

> How can I solve that?

Fix the timing in culfw @ CUNO. I've never tested the FHT8v code with a CUNO,
only with a CUL.

> And what does this message mean, do I have to define anything else besides
> the "define wz FHT8V 1234"?

autocreate is not "X67" compatible, but this is only annoying if you are
debugging. I suggest removeing autocreate as long as you are using X67.

[Alex van Hoboken]

> Fix the timing in culfw @ CUNO. I've never tested the FHT8v code with a CUNO,
> only with a CUL

Sounds easy but where can I find information how to do that?

[Rudolf Koenig]

> Sounds easy but where can I find information how to do that?

In the culfw source and in some books like K&R. No more help from me in this
case.

[Alex van Hoboken]

Ok thanks. I hope I can confirm your theory some day :)

[Alex van Hoboken]

update...
I decided that it was easier to buy an additional CUL than try to fix
the timing
I hope to receive my CC1101-USB-Lite 868MHz next week and get these
FHT8V properly working.

> > case.- Tekst uit oorspronkelijk bericht niet weergeven -

[DT]

The issue has been fix and commited to svn.

See:
http://groups.google.com/group/cul-fans/browse_thread/thread/83b55bbfec7904a0

[Alex van Hoboken]

Thanks. I guess I have to compile the sources before this will have
any effect on my CUNO. I tried this offcourse but failed to get all
the neccesary packages installed on my ubuntu system. Can someone help
me out here and create a updated CUNO.hex for me?

Thanks,
Alex

On 19 jan, 01:51, DT <tostm...@gmail.com> wrote:
> The issue has been fix and commited to svn.
>

> See:http://groups.google.com/group/cul-fans/browse_thread/thread/83b55bbf...

[Dirk Tostmann]

Follow the link to the cul-fans group. There is a hex file of current firmware attached!

[Alex van Hoboken]

Is that version (CUNO2) also compatible with the first generation
CUNO?

[Dirk Tostmann]

Am 21.01.2012 um 17:46 schrieb Alex van Hoboken:

> Is that version (CUNO2) also compatible with the first generation
> CUNO?

Of course not, but CUNO V1 shouldn't have had this timing problem as it does not support Infrared at all ... ?!?!

The CUNO / CUNO2 hex files in svn contain the patch now - just try those.

[Alex van Hoboken]

I tried the new files from the svn and flashed my CUNO again but the
problem remains. Using a CUL I've got no problem controlling a FHT8v
directly but on a CUNO it seems that there is still a timing problem.
Messages are send approx every 118s instead of 117.
Does anyone has this working combination (CUNOv1/FHT8V) working?

Thanks,
Alex

[Dirk Tostmann]

Am 23.01.2012 um 15:48 schrieb Alex van Hoboken:

> CUNO it seems that there is still a timing problem.

CUNO v1 has no crystal osc.

You should try manually re-calibrating a CUNO oscillator following the steps:
* run CUNO in Bootloader mode by powering it up with button on its back pressed
* Connect to it with a 38400 baud terminal
* Press 'S' to see if something gets returned
* Then: Press 'C' (capital c) serveral times, or hold it for 5 seconds. This will return something like: "B9 00D0 B8"
* repeat the previous step until the number in the middle is: "?? 00D0 ??"
Than your CUNO osc runs at correct speed to allow proper serial communication with your host.
* Recycle power on CUNO - firmware won't be touched