Hi,
I experimented with CUL today. CUL_FTTK apparently has a software defect
which manifests itself as follows:
fhem.log:
2009.12.13 17:25:24 0: Server started (version =VERS= from =DATE= ($Id:
fhem.pl,v 1.91 2009/12/09 13:29:47 rudolfkoenig E
xp $), pid 31035)
2009.12.13 17:26:04 3: FHTTK skipping state 02 as last similar telegram
was received less than 5 secs ago
2009.12.13 17:26:05 3: FHTTK skipping state 02 as last similar telegram
was received less than 5 secs ago
Use of uninitialized value $self in hash element at
/data/Homeautomation/fhem/FHEM/09_CUL_FHTTK.pm line 189.
Use of uninitialized value $self in hash element at
/data/Homeautomation/fhem/FHEM/09_CUL_FHTTK.pm line 199.
Use of uninitialized value $self in hash element at
/data/Homeautomation/fhem/FHEM/09_CUL_FHTTK.pm line 201.
etc.
Many perl error message follow.
xmllist lists an unnamed device at the beginning which breaks pgm3:
< name="" state="" sets="" attrs="room comment">
measured="2009-12-13 17:28:46"/>
<_internal__LIST>
<_internal_ name="global" state="<no definition>"
sets="" attrs="room comment archivecmd allowfrom archivedir configfile
lastinclude logfile modpath nrarchive pidfilename port statefile title
userattr verbose:1,2,3,4,5 mseclog version nofork logdir holiday2we">
etc.
The fhem.save contains invalid (unnamed) devices:
#Sun Dec 13 17:25:17 2009
setstate Battery
setstate PREV
setstate Reliability
setstate Warning
setstate 2009-12-13 17:24:31 Window Closed
How to fix this?
Regards,
Boris
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Dr. Boris Neubert wrote:
> Hi,
>
> I experimented with CUL today. CUL_FTTK apparently has a software defect
> which manifests itself as follows:
>
> fhem.log:
>
> 2009.12.13 17:25:24 0: Server started (version =VERS= from =DATE= ($Id:
> fhem.pl,v 1.91 2009/12/09 13:29:47 rudolfkoenig E
> xp $), pid 31035)
Haven't ugraded to latest release yet, therefore I can't reproduce this
right now. I don't have the perl errors in my development code, as for
XML and fhem.save, XML I never (knowingly) used, in my fhem.save I don't
have strange entries without a device name.
"Server started (version =VERS= from =DATE=", which version are you using?
Mine says:
2009.12.13 12:31:31 0: Server started (version 4.7 from 2009-10-23 ($Id: fhem.pl,v 1.80 2009/09/11 07:34:12 rudolfkoenig Exp $), pid 30648)
Regards,
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Kai 'wusel' Siering schrieb:
> Dr. Boris Neubert wrote:
>
>> I experimented with CUL today. CUL_FTTK apparently has a software defect
>>
> "Server started (version =VERS= from =DATE=", which version are you using?
>
>
I use the CVS version as of 2009-12-12 (yesterday) of fhem and culfw V1.33.
The error occurs after 0 .. 2 minutes, presumably after having received
the first message.
Maybe the following may hint to the source of the problem: I did not
define a device for all FHT80TFK because I did not receive a telegram
from one of them. Could the problem be caused by this unknown device?
grep Window fhem.log
2009.12.13 18:28:02 4: FHTTK Device (Window: Closed)
<----- this is the rogue device
2009.12.13 18:29:56 4: FHTTK Device x.5.fk (Window: Closed)
2009.12.13 18:30:36 4: FHTTK Device x.2.fk (Window: Closed)
Regards,
Boris
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Hello,
Dr. Boris Neubert schrieb:
> Kai 'wusel' Siering schrieb:
>
>> Dr. Boris Neubert wrote:
>>
>>
>>> I experimented with CUL today. CUL_FTTK apparently has a software defect
>>>
>>>
I would like to confirm the defect in CUL_FTTK. It is easy to reproduce
for me:
1. Do not define any CUL_FTTK device.
2. Connect to fhem and load the module:
reload 09_CUL_FHTTK.pm
3. Wait until the first datagram from a window sensor is received.
=> There appear many messages about unitialized variables from the perl
module. I presume that the Parse function does not handle undefined
devices well.
Regards,
Boris
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
> I would like to confirm the defect in CUL_FTTK. It is easy to reproduce
> for me:
I'm afraid this is not a special problem of the CUL_FTTK module, but it is a
general problem of the reload function. Each module remembers the code ->
device structure information in a local hash (%defptr). It was reported, that
this data structure gets lost after a reload. We have to verify it and think
about a solution.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Am 19.12.2009 17:44, schrieb Rudolf Koenig:
>> I would like to confirm the defect in CUL_FTTK. It is easy to reproduce
>> for me:
>>
> I'm afraid this is not a special problem of the CUL_FTTK module, but it is a
> general problem of the reload function. Each module remembers the code ->
> device structure information in a local hash (%defptr). It was reported, that
> this data structure gets lost after a reload. We have to verify it and think
> about a solution.
>
I would like to add that I executed the sequence in my original post
after a restart of fhem with no devices defined. The reload command was
issued to bring the CUL_FTTK module to live without the need to define a
window sensor.
Regards,
Boris
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Hallo Zusammen,
> Each module remembers the code ->device structure information in a local hash (%defptr).
By reloading a Modul this structure %defptr gets lost.
F.e.:
- define KS1 ks300 1234
- MyCUN: K97250108001B46 -74.5
- reload 13_KS300.pm
- Unkown KS300 ... please define it
- Modify KS1: change code form 1234 to 4321
- MyCUN: K97250108001B46 -74.5
Schöne Grüße
Axel
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.