Hallo,
Modul für den Tekelek TEK603 Eco Monitor, Füllstandsmessung für Öltanks und Zisternen.
Über Anregungen und Verbesserungen würde ich mich freuen.
Name des Moduls im SVN: 44_TEK603.pm
Grüße
Stephan
Habe bei mir den Proteus TEK603 Niveausensor im Einsatz und möchte diesen an FHEM anbinden für die Aufzeichung des Niveau und Alarmierung.
Der Datenlogger wird auch im FHEM angelegt.
DEF /dev/ttyUSB3@38400
DeviceName /dev/ttyUSB3@38400
NAME TRX_3
NR 138
PARTIAL
STATE opened
TYPE TRX
Nur die Daten die eingelesen werden sind nicht zu gebrauchen.
CODE 1c
DEF 1c
IODev TRX_3
NAME TRX_UNKNOWN_1c
NR 140
STATE 1c1cfc0000e01c1c1c00e0000000fc00000000001c1cfc0000e0000000
TYPE TRX_ELSE
Was muß noch angepasst werden?
einfach den Empfänger Proteus EcoMeterMonitor (http://hausautomatisierung.co/haustechnik/ecometer-ultraschall-fuellstandsanzeige-fuer-heizoeltank/) via USB an den Raspberry Pi anschließen und FHEM mit
define Niveausensor TEK603 /dev/ttyUSB3
konfigurieren.
Niveau wird dann als "Ullage" und in Liter als "RemainingUsableLevel" angezeigt.
Das Modul TRX wird nicht benötigt.
Hallo Eisler!
Niveau "Ullage" und in Liter als "RemainingUsableLevel" werden angelegt aber mit unreellen Daten angezeigt.
Wie muß ich das definieren?
Außer das Korrekte /dev/ttyUSBx also z.B. /dev/ttyUSB1 muss nichts weiter definiert werden.
Bitte in die Ausgabe von dmesg schauen.
Da sollte sich so was wie:
usb 1-1.3: cp210x converter now attached to ttyUSB0
finden.
Kann bei mir dmsg nicht finden.
In welcher Datei genau befindet sich diesen Eintrag?
Einfach auf der Linux Kommandozeile dmesg eingeben.
Alternativ geht es auch über die FHEM Befehlszeile im Webinterface mit:
{ my $dmesg = `dmesg` }
Danke für den Tipp.
Habe einen Eintrag gefunden:
[ 3.686944] usb 1-1.4: cp210x converter now attached to ttyUSB1
Nur kann das nicht stimmen, da ich definitiv den USB3 Anschluß mit dem TEK603 verwende.
Hier werden auch die Readings angelegt bzw. aktuallisiert, nur sind das Einträge die keinen Sinn ergeben.
Zitatpi@ccs-ht-rasp ~ $ dmesg
[ 0.000000] Booting Linux on physical CPU 0xf00
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 4.1.6-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #810 SMP PREEMPT Tue Aug 18 15:32:12 BST 2015
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1
[ 0.000000] cma: Reserved 8 MiB at 0x3d800000
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] On node 0 totalpages: 253952
[ 0.000000] free_area_init_node: node 0, pgdat 8085af80, node_mem_map bcf3a000
[ 0.000000] Normal zone: 2232 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 253952 pages, LIFO batch:31
[ 0.000000] [bcm2709_smp_init_cpus] enter (9420->f3003010)
[ 0.000000] [bcm2709_smp_init_cpus] ncores=4
[ 0.000000] PERCPU: Embedded 13 pages/cpu @bcef9000 s20608 r8192 d24448 u53248
[ 0.000000] pcpu-alloc: s20608 r8192 d24448 u53248 alloc=13*4096
[ 0.000000] pcpu-alloc: - 0
- 1
- 2
- 3
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 251720
[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa01041 bcm2709.serial=0x19142f2d smsc95xx.macaddr=B8:27:EB:14:2F:2D bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3ea00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 cgroup_enable=memory elevator=deadline rootwait
[ 0.000000] Enabling memory control group subsystem
[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 988236K/1015808K available (5958K kernel code, 534K rwdata, 1644K rodata, 420K init, 757K bss, 19380K reserved, 8192K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xbe800000 - 0xff000000 (1032 MB)
[ 0.000000] lowmem : 0x80000000 - 0xbe000000 ( 992 MB)
[ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB)
[ 0.000000] .text : 0x80008000 - 0x80774c6c (7604 kB)
[ 0.000000] .init : 0x80775000 - 0x807de000 ( 420 kB)
[ 0.000000] .data : 0x807de000 - 0x80863af4 ( 535 kB)
[ 0.000000] .bss : 0x80866000 - 0x8092378c ( 758 kB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Additional per-CPU info printed with stalls.
[ 0.000000] NR_IRQS:608
[ 0.000000] Architected cp15 timer(s) running at 19.20MHz (virt).
[ 0.000000] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[ 0.000009] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[ 0.000030] Switching to timer-based delay loop, resolution 52ns
[ 0.000317] Console: colour dummy device 80x30
[ 0.002104] console [tty1] enabled
[ 0.002169] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[ 0.002268] pid_max: default: 32768 minimum: 301
[ 0.002638] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.002707] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.004038] Initializing cgroup subsys blkio
[ 0.004120] Initializing cgroup subsys memory
[ 0.004216] Initializing cgroup subsys devices
[ 0.004278] Initializing cgroup subsys freezer
[ 0.004351] Initializing cgroup subsys net_cls
[ 0.004461] CPU: Testing write buffer coherency: ok
[ 0.004583] ftrace: allocating 20203 entries in 60 pages
[ 0.054064] CPU0: update cpu_capacity 1024
[ 0.054151] CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
[ 0.054198] [bcm2709_smp_prepare_cpus] enter
[ 0.054356] Setting up static identity map for 0x8240 - 0x8274
[ 0.113937] [bcm2709_boot_secondary] cpu:1 started (0) 18
[ 0.114244] [bcm2709_secondary_init] enter cpu:1
[ 0.114296] CPU1: update cpu_capacity 1024
[ 0.114305] CPU1: thread -1, cpu 1, socket 15, mpidr 80000f01
[ 0.133921] [bcm2709_boot_secondary] cpu:2 started (0) 16
[ 0.134171] [bcm2709_secondary_init] enter cpu:2
[ 0.134201] CPU2: update cpu_capacity 1024
[ 0.134210] CPU2: thread -1, cpu 2, socket 15, mpidr 80000f02
[ 0.153956] [bcm2709_boot_secondary] cpu:3 started (0) 17
[ 0.154135] [bcm2709_secondary_init] enter cpu:3
[ 0.154164] CPU3: update cpu_capacity 1024
[ 0.154173] CPU3: thread -1, cpu 3, socket 15, mpidr 80000f03
[ 0.154267] Brought up 4 CPUs
[ 0.154401] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[ 0.154444] CPU: All CPU(s) started in SVC mode.
[ 0.155448] devtmpfs: initialized
[ 0.180237] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
[ 0.180595] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.181787] pinctrl core: initialized pinctrl subsystem
[ 0.182618] NET: Registered protocol family 16
[ 0.188389] DMA: preallocated 4096 KiB pool for atomic coherent allocations
[ 0.189629] bcm2709.uart_clock = 3000000
[ 0.194643] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.194715] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.194951] Serial: AMBA PL011 UART driver
[ 0.195173] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 83, base_baud = 0) is a PL011 rev2
[ 0.195800] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[ 0.265556] bcm2708-dmaengine 3f007000.dma: DMA legacy API manager at f3007000, dmachans=0x7f35
[ 0.266164] bcm2708-dmaengine 3f007000.dma: Load BCM2835 DMA engine driver
[ 0.266217] bcm2708-dmaengine 3f007000.dma: dma_debug:0
[ 0.266984] SCSI subsystem initialized
[ 0.267252] usbcore: registered new interface driver usbfs
[ 0.267405] usbcore: registered new interface driver hub
[ 0.267605] usbcore: registered new device driver usb
[ 0.268351] raspberrypi-firmware soc:firmware: Attached to firmware from 2015-09-02 14:58
[ 0.295712] Switched to clocksource arch_sys_counter
[ 0.345571] FS-Cache: Loaded
[ 0.346088] CacheFiles: Loaded
[ 0.359513] NET: Registered protocol family 2
[ 0.360931] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.361128] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.361368] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.361521] UDP hash table entries: 512 (order: 2, 16384 bytes)
[ 0.361617] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[ 0.362028] NET: Registered protocol family 1
[ 0.362562] RPC: Registered named UNIX socket transport module.
[ 0.362617] RPC: Registered udp transport module.
[ 0.362655] RPC: Registered tcp transport module.
[ 0.362692] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.363848] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
[ 0.365331] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.381350] VFS: Disk quotas dquot_6.6.0
[ 0.381786] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.384441] FS-Cache: Netfs 'nfs' registered for caching
[ 0.385659] NFS: Registering the id_resolver key type
[ 0.385831] Key type id_resolver registered
[ 0.385872] Key type id_legacy registered
[ 0.388648] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 0.388906] io scheduler noop registered
[ 0.388963] io scheduler deadline registered (default)
[ 0.389322] io scheduler cfq registered
[ 0.391893] BCM2708FB: allocated DMA memory fdc00000
[ 0.391972] BCM2708FB: allocated DMA channel 0 @ f3007000
[ 0.397586] Console: switching to colour frame buffer device 82x26
[ 0.402807] Serial: 8250/16550 driver, 0 ports, IRQ sharing disabled
[ 0.405684] vc-cma: Videocore CMA driver
[ 0.407397] vc-cma: vc_cma_base = 0x00000000
[ 0.409066] vc-cma: vc_cma_size = 0x00000000 (0 MiB)
[ 0.410676] vc-cma: vc_cma_initial = 0x00000000 (0 MiB)
[ 0.412438] vc-mem: phys_addr:0x00000000 mem_base=0x3ea00000 mem_size:0x3f000000(1008 MiB)
[ 0.431723] brd: module loaded
[ 0.442321] loop: module loaded
[ 0.444778] vchiq: vchiq_init_state: slot_zero = 0xbdc80000, is_master = 0
[ 0.448059] Loading iSCSI transport class v2.0-870.
[ 0.450506] usbcore: registered new interface driver smsc95xx
[ 0.452137] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 0.654015] Core Release: 2.80a
[ 0.655486] Setting default values for core params
[ 0.657036] Finished setting default values for core params
[ 0.858958] Using Buffer DMA mode
[ 0.860472] Periodic Transfer Interrupt Enhancement - disabled
[ 0.862033] Multiprocessor Interrupt Enhancement - disabled
[ 0.863628] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 0.865197] Dedicated Tx FIFOs mode
[ 0.867108] WARN::dwc_otg_hcd_init:1047: FIQ DMA bounce buffers: virt = 0xbdc14000 dma = 0xfdc14000 len=9024
[ 0.870302] FIQ FSM acceleration enabled for :
[ 0.870302] Non-periodic Split Transactions
[ 0.870302] Periodic Split Transactions
[ 0.870302] High-Speed Isochronous Endpoints
[ 0.876803] dwc_otg: Microframe scheduler enabled
[ 0.876884] WARN::hcd_init_fiq:412: FIQ on core 1 at 0x80401038
[ 0.878530] WARN::hcd_init_fiq:413: FIQ ASM at 0x80401394 length 36
[ 0.880183] WARN::hcd_init_fiq:438: MPHI regs_base at 0xbe89a000
[ 0.881824] dwc_otg 3f980000.usb: DWC OTG Controller
[ 0.883443] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[ 0.885087] dwc_otg 3f980000.usb: irq 32, io mem 0x00000000
[ 0.886739] Init: Port Power? op_state=1
[ 0.888284] Init: Power Port (0)
[ 0.890077] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.891679] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.893263] usb usb1: Product: DWC OTG Controller
[ 0.894810] usb usb1: Manufacturer: Linux 4.1.6-v7+ dwc_otg_hcd
[ 0.896401] usb usb1: SerialNumber: 3f980000.usb
[ 0.898890] hub 1-0:1.0: USB hub found
[ 0.900473] hub 1-0:1.0: 1 port detected
[ 0.902395] dwc_otg: FIQ enabled
[ 0.902410] dwc_otg: NAK holdoff enabled
[ 0.902421] dwc_otg: FIQ split-transaction FSM enabled
[ 0.902462] Module dwc_common_port init
[ 0.902852] usbcore: registered new interface driver usb-storage
[ 0.904589] mousedev: PS/2 mouse device common for all mice
[ 0.906994] bcm2835-cpufreq: min=600000 max=900000
[ 0.908830] sdhci: Secure Digital Host Controller Interface driver
[ 0.910359] sdhci: Copyright(c) Pierre Ossman
[ 0.912320] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0
[ 0.913880] mmc-bcm2835 3f300000.mmc: DMA channels allocated
[ 0.946065] sdhci-pltfm: SDHCI platform and OF driver helper
[ 0.952705] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.954570] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.956511] usbcore: registered new interface driver usbhid
[ 0.958149] usbhid: USB HID core driver
[ 0.960153] Initializing XFRM netlink socket
[ 0.961806] NET: Registered protocol family 17
[ 0.966882] Key type dns_resolver registered
[ 0.968975] Registering SWP/SWPB emulation handler
[ 0.971547] registered taskstats version 1
[ 0.973304] vc-sm: Videocore shared memory driver
[ 0.974790] [vc_sm_connected_init]: start
[ 0.976639] vc_vchi_sm_init: failed to open VCHI service (-1)
[ 0.976772] [vc_sm_connected_init]: failed to initialize shared memory service
[ 0.979776] [vc_sm_connected_init]: end - returning -1
[ 0.982932] Waiting for root device /dev/mmcblk0p2...
[ 1.014277] mmc0: host does not support reading read-only switch, assuming write-enable
[ 1.020659] mmc0: new high speed SDHC card at address 0002
[ 1.022959] mmcblk0: mmc0:0002 SD16G 14.9 GiB
[ 1.027487] mmcblk0: p1 p2
[ 1.095874] Indeed it is in host mode hprt0 = 00021501
[ 1.105803] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 1.109080] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 1.111972] devtmpfs: mounted
[ 1.114368] Freeing unused kernel memory: 420K (80775000 - 807de000)
[ 1.275782] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 1.277854] Indeed it is in host mode hprt0 = 00001101
[ 1.476144] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[ 1.478110] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.480918] hub 1-1:1.0: USB hub found
[ 1.482942] hub 1-1:1.0: 5 ports detected
[ 1.765897] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[ 1.866207] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[ 1.868175] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.873125] smsc95xx v1.0.4
[ 1.931538] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:14:2f:2d
[ 2.015840] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[ 2.286574] udevd[174]: starting version 175
[ 2.497916] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001
[ 2.501683] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.503645] usb 1-1.2: Product: FT232R USB UART
[ 2.505559] usb 1-1.2: Manufacturer: FTDI
[ 2.507547] usb 1-1.2: SerialNumber: A98J3XX9
[ 2.635872] usb 1-1.3: new full-speed USB device number 5 using dwc_otg
[ 3.118612] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
[ 3.122495] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.124537] usb 1-1.3: Product: FT232R USB UART
[ 3.126641] usb 1-1.3: Manufacturer: FTDI
[ 3.128616] usb 1-1.3: SerialNumber: A9ULXRVF
[ 3.255827] usb 1-1.4: new full-speed USB device number 6 using dwc_otg
[ 3.365137] usb 1-1.4: New USB device found, idVendor=10c4, idProduct=ea60
[ 3.367139] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.369012] usb 1-1.4: Product: CP2102 USB to UART Bridge Controller
[ 3.370828] usb 1-1.4: Manufacturer: Silicon Labs
[ 3.372563] usb 1-1.4: SerialNumber: 0001
[ 3.455768] usb 1-1.5: new full-speed USB device number 7 using dwc_otg
[ 3.581758] usb 1-1.5: New USB device found, idVendor=0403, idProduct=6001
[ 3.583509] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.585198] usb 1-1.5: Product: RFXtrx433
[ 3.586863] usb 1-1.5: Manufacturer: RFXCOM
[ 3.588496] usb 1-1.5: SerialNumber: A1YUXLCQ
[ 3.590959] random: nonblocking pool is initialized
[ 3.651794] usbcore: registered new interface driver usbserial
[ 3.653697] usbcore: registered new interface driver usbserial_generic
[ 3.655403] usbserial: USB Serial support registered for generic
[ 3.674230] usbcore: registered new interface driver ftdi_sio
[ 3.676208] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 3.677470] usbcore: registered new interface driver cp210x
[ 3.679518] usbserial: USB Serial support registered for cp210x
[ 3.681462] cp210x 1-1.4:1.0: cp210x converter detected
[ 3.681870] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[ 3.682076] usb 1-1.2: Detected FT232RL
[ 3.686944] usb 1-1.4: cp210x converter now attached to ttyUSB1
[ 3.688778] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 3.690786] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[ 3.694537] usb 1-1.3: Detected FT232RL
[ 3.699244] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB2
[ 3.701630] ftdi_sio 1-1.5:1.0: FTDI USB Serial Device converter detected
[ 3.704078] usb 1-1.5: Detected FT232RL
[ 3.708468] usb 1-1.5: FTDI USB Serial Device converter now attached to ttyUSB3
[ 5.175999] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 5.440838] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 9.900119] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[ 11.528347] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[ 13.154053] cfg80211: Calling CRDA to update world regulatory domain
[ 16.305777] cfg80211: Calling CRDA to update world regulatory domain
[ 19.465796] cfg80211: Calling CRDA to update world regulatory domain
[ 22.625815] cfg80211: Calling CRDA to update world regulatory domain
[ 25.785827] cfg80211: Calling CRDA to update world regulatory domain
[ 26.238881] uart-pl011 3f201000.uart: no DMA platform data
[ 28.945844] cfg80211: Calling CRDA to update world regulatory domain
[ 32.105828] cfg80211: Calling CRDA to update world regulatory domain
[ 35.265803] cfg80211: Calling CRDA to update world regulatory domain
[ 38.425847] cfg80211: Calling CRDA to update world regulatory domain
[ 41.585854] cfg80211: Calling CRDA to update world regulatory domain
[ 44.745890] cfg80211: Calling CRDA to update world regulatory domain
[ 47.905895] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
Das passt schon mit ttyUSB1
Testen kann man das einfach mit USB Stecker des EcoMeterMonitor ( TEK603 ) abziehen und neu anstecken.
Dann noch mal mit dmesg schauen welches ttyUSB verwendet wird.
Zum besseren Debuggen kann man auch den Sensor und den Monitor neu pairen.
Nach der Paarung der Geräte sendet der Sensor für ungefähr 10 Minuten kontinuierlich
Daten zum Proteus Monitor (Echtzeitmodus) und damit auch zum FHEM.
Mit dem Aufruf
ls -al /dev/serial/by-id
sieht man eigentlich leichter welche Schnittstellen momentan aktiv sind.
Eigentlich müsste der Eintrag unter DEF auch so funktionieren.
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
Damit wäre die Definition eindeutig wenn ein anderer Port verwendet werden sollte, solange kein gleiches USB Gerät angeschlossen wird welches keine Seriennummer besitzt.
Gelöst!!
Schnittstelle in der Form eingetragen:
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
Und die Daten kommen an.
@eisler
Folgende Punkte wären nicht schlecht:
Bei der Anlage des Device TEK603 sollten schon die Plotdefinitionen automatisch angelegt werden.
ZB:
Zitat# Proteus
define TEK603 TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
attr TEK603 alias Muehlbachniveau
attr TEK603 icon time_graph
attr TEK603 room _RxTx
define FileLog_TEK603_RUL FileLog /media/hdd/fhem/log/TEK603_RUL-%Y-%m.log TEK603:RemainingUsableLevel:.*|TEK603_RUL
attr FileLog_TEK603_RUL room _LOG
define SVG_FileLog_TEK603_RUL SVG FileLog_TEK603_RUL:SVG_FileLog_TEK603_RUL:CURRENT
attr SVG_FileLog_TEK603_RUL label "TEK603_RUL Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_FileLog_TEK603_RUL room Wetterstation
define FileLog_TEK603_TEMP FileLog /media/hdd/fhem/log/TEK603_TEMP-%Y-%m.log TEK603:Temperature:.*|TEK603_TEMP
attr FileLog_TEK603_TEMP room _LOG
define SVG_FileLog_TEK603_TEMP SVG FileLog_TEK603_TEMP:SVG_FileLog_TEK603_TEMP:CURRENT
attr SVG_FileLog_TEK603_TEMP label "TEK603_TEMP Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_FileLog_TEK603_TEMP room Wetterstation
define FileLog_TEK603_TUC FileLog /media/hdd/fhem/log/TEK603_TUC-%Y-%m.log TEK603:TotalUsableCapacity:.*|TEK603_TUC
attr FileLog_TEK603_TUC room _LOG
define FileLog_TEK603_U FileLog /media/hdd/fhem/log/TEK603_U-%Y-%m.log TEK603:Ullage:.*|TEK603_U
attr FileLog_TEK603_U room _LOG
define SVG_FileLog_TEK603_U SVG FileLog_TEK603_U:SVG_FileLog_TEK603_U:CURRENT
attr SVG_FileLog_TEK603_U label "TEK603_U Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_FileLog_TEK603_U room Wetterstation
Weiters wäre es eine Gute Idee die Konfiguration des TEK603 durchführen zu können:
Volumen, Leerraum oben, Boden Bereich, Type Behältniss, Offset Volumen, Offset Innen- und Aussentemp, Logintervall variabel machen.
Was mir beim Dattenlogging auffällt ist das der Leerraum und die Sensortemperatur immer wieder Werte liefert die nicht stimmen können.
Vielleicht könnten wir gemeinsam noch entsprechende Verbesserungen des TEK603 Gerätes erarbeiten.
> Bei der Anlage des Device TEK603 sollten schon die Plotdefinitionen automatisch angelegt werden.
Machen das andere FHEM Module auch so? Evt. genügt eine Anleitung im Wiki?
>Weiters wäre es eine Gute Idee die Konfiguration des TEK603 durchführen zu können:
>Volumen, Leerraum oben, Boden Bereich, Type Behältniss, Offset Volumen, Offset Innen- und Aussentemp, Logintervall variabel machen.
steht schon auf der TODO Liste. Für Aussentemp, Logintervall warte ich auf Feedback vom Hersteller.
>Was mir beim Dattenlogging auffällt ist das der Leerraum und die Sensortemperatur immer wieder Werte liefert die nicht stimmen können.
Stimmt von zeit zu zeit werden Werte übertragen die nicht stimmen können. Das Problem sollte sich mit einer CRC32 Validierung beheben lassen.
Mein berechneter CRC32 Wert passt aber leider nicht zur Prüfsumme.
>Vielleicht könnten wir gemeinsam noch entsprechende Verbesserungen des TEK603 Gerätes erarbeiten.
Da spricht nichts dagegen.
@eisler
Einige Geräte die ich in Verwendung habe haben schon alles automatisch bei der Anlage dabei.
Aber zu Not kann die Help Info beim TEK603 mit entsprechender Info gefüttert werden.
So zb. die Oregon Wettersensoren. Sowie dieser erkannt wird, werden alle Grundkonfigurationen automatisch durchgeführt. Es werden die Anzeigen der Sensorwerte erstellt, und die Plot werden entsprechend auch schon angelegt.
Dies trifft bei vielen anderen Sensoren auch zu. Ebenfalls werden die Batterie Zustände übermittelt, die dann für Infos herangezogen werden können bevor der Sensor ausfällt.
Für die Schnittstellenkonfiguration ist jedenfalls die angegebene define TEK603 TEK603 /dev/ttyUSBx nicht ratsam, da sich diese sehr schnell bei einem Neustart ändern kann.
Die Schnittstellenkonfiguration sollte in der Form angelegt werden.
define TEK603 TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
Es ist nur schade das diese USB Schnittstelle keine Seriennummer mitliefert, denn wenn mehrere USB Geräte mit diesem Schnittstellen Device angeschlossen werden ist das nächste Problem gegeben, wo jetzt das richtige angeschlossen ist.
Bei meinen selbstgebauten Schnittstellen verwende ich ausschließlich den FT232R, wo jedes Gerät eine andere Seriennummer von hausaus besitzt.
Sieht dann so aus: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A98J3XX9-if00-port0@38400 0000
Also bin schon gespannt auf die neue Firmware für den Monitor.
Wie sieht es eigentlich bei dem Sendemodul aus.
Welche Frequenz nutz die Sensor Monitor Einheit.
Eigenlich müsste eine lowcost Variante auch möglich sein, die nur aus der Sensor und Sendeeinheit besteht und für FHEM genutz werden könnte.
Hallo,
hab gerade mit dem Support gesprochen nächstes Jahr soll eine Industrieversion mit 230V Anschluß und ~30s Übermittlungsfrequenz kommen. Sendeprotokoll bleibt proprietär. Der Sensor überträgt nur Entfernungswerte laut Anleitung aber auf 433MHZ. Wobei beim EcoSens 868 MHZ steht. !?!
Wie sind die Erfahrungen mit dem Teil bis jetzt?
Gruß
Eisix
Bis auf die fehlerhaften Werte von Temperature und Ullage bekomme ich ca. alle 30min Werte vom Proteus EcoMeter S.
Dieser Fehler ist auch mit der neuen Firmware immer noch vorhanden.
Eines ist mir aufgefallen das zwar ein Offset für das Niveau jetzt im Menü zu definieren vorhanden ist.
Der Bodentotraum ist mir nicht untergekommen.
Ein Batterie Zustand als Info wäre auch nicht schlecht zumindest für das FHEM.
Ein weiterer Fehler der ständig auftritt besteht darin, dass auf einmal jede Sekunde alle Werte eingelesen werden die zudem auch teilweise fehlerhaft sind.
Diese stoppen nach ca. 30Minuten wieder eigenständig und tritt erst wieder nach längerer Zeit auf.
Siehe Anhang.
Hallo,
ich habe heute mal das Modul ausprobiert, jedoch bekomme ich keine vernünftigen Werte:
Internals:
CFGFN
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
FD 92
NAME OelTank
NR 1654
PARTIAL
PORTSTATE open
STATE opened
TYPE TEK603
buffer 5349001602100c2338000000000000007fff0bb8609a
Readings:
2015-12-29 12:36:44 RemainingUsableLevel 32767
2015-12-29 12:36:44 Temperature -40.00
2015-12-29 12:36:44 Time 12:35:56
2015-12-29 12:36:44 TotalUsableCapacity 3000
2015-12-29 12:36:44 Ullage 0
2015-12-29 11:46:07 state opened
Am Monitor werden aber die richtigen Werte angezeigt.
Klaus
Welche Werte stimmen bei dir nicht?
Die Werte RemainingUsableLevel und TotalUsableCapacity müssten Großteils stimmen.
Temperature und Ullage werden nur ca. jeden zweiten Zyclus richtig eingelesen.
Da besteht leider so weit ich weis ein Firmware Fehler der noch nicht gelöst wurde.
Nach einigen Stunden kamen dann doch alle Werte, wobei Ullage und Temperatur meist fhelerhafte Werte liefert. Da ich diese aber nicht auswerte, kann ich damit leben :)
Ansonsten, Danke für das Modul
Hallo,
das übertragen falscher Werte an FHEM ist gefixt.
Dazu wird das Perl Modul Digest::CRC benötigt.
Falls nicht vorhanden kann das Modul auf Debian basierten Systemen mit
sudo apt-get install libdigest-crc-perl
installiert werden.
Grüße
Stephan
Nach der Aktuallisierung mit
sudo apt-get install libdigest-crc-perl
und update 44_TEK603.pm
(# $Id: 44_TEK603.pm 10663 2016-01-30 10:31:14Z eisler $) und anschließendem reboot wurde keine Änderung am Verhalten festgestellt.
Verwendet Firmware V22.4 Wasser.hex
Nach wie vor werden fehlerhafte Werte bei der Sensor Temperatur und dem oberern Leerraum festgestellt!
Hallo,
Ursache des Problem mit Temperature und Ullage wurde gefunden und gefixt.
Im EcoMeter intern gibt es einen Status TankLevel=NO_DATA der jetzt berücksichtigt wird.
Grüße
Stephan
Ab wann ist ein Firmware Update zu finden.
Reicht das Firmware Update oder sind betreffend FHEM auch Updates nötig?
In der Firmware wird leider nichts gefixt. Ich habe das im FHEM TEK603 Modul gefixt.
Also reicht ein FHEM Update des TEK603 Moduls.
Kleines Modul Update. Temperature und Ullage sollten jetzt nur noch korrekte Werte liefern.
Habe das update 44_TEK603.pm
# $Id: 44_TEK603.pm 10987 2016-03-04 10:23:40Z eisler $ ausgeführt.
Geändert hat sich aber nichts.
Nach wie vor der gleiche Fehler.
War noch ein kleiner Fehler. Habe ich heute gefixt. -> "Kleines Modul Update."
$Id: 44_TEK603.pm 10993 2016-03-05 08:55:29Z eisler $
@eisler
Mit diesem Update werden alle Werte bisher sauber eingelesen.
Danke fürs Feedback! :) Bis jetzt waren bei mir auch alle Werte ok.
Hallo
Ich habe dieses Modul mal ausprobiert und die Werte werden sauber gelesen. Vielen Dank für die tolle Arbeit :)
Nur ein Problem habe. Das Intervall des Datenabrufs aus dem Ecometer ist sehr unterschiedlich und dauert manchmal einige Stunden. Kann man denn dieses Intervall einstellen bzw. welche Systematik steckt dahinter?
Danke und viele Grüße,
Frank
Hallo,
Um eine maximale Lebensdauer der Batterien zu erreichen empfängt und interpretiert der Monitor die Messdaten in 60min Intervallen. Einstellen kann man das leider nicht, das ist abhängig von der Firmware.
Beim EcoMeter S für Zisterne, Wassertank sind das 30min Intervalle. Er misst aber in Echtzeit, sobald eine Füllstandsänderung von ≥3cm/min erfasst wird.
Grüße,
Stephan
Hi Stephan,
vielen Dank für das coole Modul! Ich bin jetzt vom KMF100S auf Ecometer umgestiegen und war sehr erleichtert, dass es in FHEM schon was dafür gibt.
Ich hätte auch eine Frage zum Timing der Daten: Wenn sich der Pegel in der Zisterne ändert, kommen ja sehr viele Datenpakete rein. Da ich diese logge um einen Plot dazustellen, wollte ich "event-on-change-reading, event-on-update-reading und event-min-interval" anwenden um die Datenflut zu bändigen. Das Modul scheint dies jedoch nicht zu unterstützen. Gibt es ggf. noch einen anderen Weg um die Datenmenge im Zaum zu halten?
Gruß
Frank
Edit: Hab es mit readingsProxy in den Griff bekommen: Einfach einen readingsProxy auf "RemainingUsableLevel" anlegen und dort die "readingFnAttribute" anlegen. Dann den readingsProxy loggen und plotten. Perfekt... ;)
Hallo Frank,
schön das du mit readingsProxy eine Lösung gefunden hast.
Wenn möglich würde ich auch gerne "event-on-change-reading, event-on-update-reading und event-min-interval" in meinem Modul unterstützen,
konnte aber noch keine passende Entwickler Dokumentation finden.
Grüße,
Stephan
Vielleicht hilft euch meine Config weiter.
Habe daraus eine Pegelmessung gemacht mit Druchflussmenge.
##############################
### INPUT ###
##############################
define proteus TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
attr proteus alias Aussenbereich - Mühlbach - Pegelmessung
attr proteus devStateIcon open:usb@red opened:usb@green
attr proteus group Schnittstellen
attr proteus icon time_graph
attr proteus room _RxTx
attr proteus userReadings RemainingUsableLevel_m3psec:RemainingUsableLevel.* {ReadingsVal("proteus","RemainingUsableLevel",0)*0.9}
attr proteus verbose 1
# -----------------------------------------------------------------------------------------------
# -----------------------------------------------------------------------------------------------
##############################
### LOG DEVICES ###
##############################
define FileLog_TEK603_RUL FileLog /media/hdd/fhem/log01/bachniveau/TEK603_RUL-%Y-%m.log proteus:RemainingUsableLevel:.*|TEK603_RUL
attr FileLog_TEK603_RUL alias Mühlbach Pegelstand
attr FileLog_TEK603_RUL logtype :,text
attr FileLog_TEK603_RUL room _LOG
define SVG_TEK603_RUL SVG FileLog_TEK603_RUL:SVG_TEK603_RUL:CURRENT
attr SVG_TEK603_RUL fixedrange month
attr SVG_TEK603_RUL group Umwelt lokal
attr SVG_TEK603_RUL label "TEK603_RUL Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_TEK603_RUL room Pegelmessung Mühlbach,Wetterstation
# attr SVG_TEK603_RUL group Umwelt lokal
# attr SVG_TEK603_RUL room Wetterstation
define FileLog_TEK603_RULm3 FileLog /media/hdd/fhem/log01/bachniveau/TEK603_RULm3-%Y-%m.log proteus:RemainingUsableLevel_m3psec:.*|TEK603_RULm3
attr FileLog_TEK603_RULm3 alias Mühlbach Durchflußmenge
attr FileLog_TEK603_RULm3 logtype :,text
attr FileLog_TEK603_RULm3 room _LOG
define SVG_TEK603_RULm3 SVG FileLog_TEK603_RULm3:SVG_TEK603_RULm3:CURRENT
attr SVG_TEK603_RULm3 fixedrange month
attr SVG_TEK603_RULm3 group Umwelt lokal
attr SVG_TEK603_RULm3 label "TEK603_RULm3 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_TEK603_RULm3 room Pegelmessung Mühlbach,Wetterstation
# attr SVG_TEK603_RULm3 group Umwelt lokal
# attr SVG_TEK603_RULm3 room Wetterstation
define FileLog_TEK603_TEMP FileLog /media/hdd/fhem/log01/bachniveau/TEK603_TEMP-%Y-%m.log proteus:Temperature:.*|TEK603_TEMP
attr FileLog_TEK603_TEMP alias Mühlbach Niveau Sensortemperatur
attr FileLog_TEK603_TEMP logtype temp4:Temp,text
attr FileLog_TEK603_TEMP room _LOG
define SVG_TEK603_TEMP SVG FileLog_TEK603_TEMP:SVG_TEK603_TEMP:CURRENT
attr SVG_TEK603_TEMP group Umwelt lokal
attr SVG_TEK603_TEMP label "TEK603_TEMP Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_TEK603_TEMP room Pegelmessung Mühlbach,Wetterstation
# attr SVG_TEK603_TEMP group Umwelt lokal
# attr SVG_TEK603_TEMP room Wetterstation
define FileLog_TEK603_TUC FileLog /media/hdd/fhem/log01/bachniveau/TEK603_TUC-%Y-%m.log proteus:TotalUsableCapacity:.*|TEK603_TUC
attr FileLog_TEK603_TUC alias Mühlbach maximales Niveau
attr FileLog_TEK603_TUC logtype :,text
attr FileLog_TEK603_TUC room _LOG
define FileLog_TEK603_U FileLog /media/hdd/fhem/log01/bachniveau/TEK603_U-%Y-%m.log proteus:Ullage:.*|TEK603_U
attr FileLog_TEK603_U alias Mühlbach Niveausensor Leerraum oben
attr FileLog_TEK603_U logtype :,text
attr FileLog_TEK603_U room _LOG
# -----------------------------------------------------------------------------------------------
# -----------------------------------------------------------------------------------------------
##############################
### GROUP ###
##############################
define proteusrg readingsGroup TYPE=TEK603:<%time_graph>,<Durchflussmenge>,RemainingUsableLevel_m3psec\
TYPE=TEK603:<%time_graph>,<Wasserstand>,RemainingUsableLevel\
TYPE=TEK603:<%temp_temperature>,<Sensortemperatur>,Temperature\
TYPE=TEK603:<%time_graph>,<Meßbereich>,TotalUsableCapacity\
TYPE=TEK603:<%time_graph>,<Leerraum>,Ullage
attr proteusrg alias Proteus Niveaumessung Mühlbach
attr proteusrg group Sensoren
attr proteusrg room Pegelmessung Mühlbach
attr proteusrg valueFormat {RemainingUsableLevel_m3psec => "%1.f m³/h",\
RemainingUsableLevel => "%1.f cm",\
Temperature => "%.1f °C",\
TotalUsableCapacity => "%1.f cm",\
Ullage => "%1.f cm"}
attr proteusrg valueStyle style="text-align:right"
# -----------------------------------------------------------------------------------------------
# -----------------------------------------------------------------------------------------------
Hi Stephan
Ich habe mal Dein Modul um einen Wert erweitert (Füllstand in Prozent). Siehe Anlage.
Kannst Du das mal testen und ggf. in Deinen Code einfügen? Mir fehlt leider ein bisschen die Zeit um einen Github Pull-Request zu starten.
Danke :)
Viele Grüße,
Frank
Hallo Frank,
habe es mir angeschaut Füllstand in Prozent sieht gut aus, kann ich so übernehmen.
Hat es ein Grund warum du
return '' if($temp eq "-40.00" && $Ullage eq "0"); # TankLevel=NO_DATA
in
return '' if($temp eq "-40" && $Ullage eq "0"); # TankLevel=NO_DATA
geändert hast?
Grüße
Stephan
Hi Stephan
Huch, die Zeile hab ich nicht angerührt - ehrlich :) Hab den Code aus der aktuelle Fhem-Version von heute morgen.
Wann ist denn das Update verfügbar?
Gruß,
Frank
Hallo Frank,
Passt, hatte ich noch im diff hast du wirklich nicht geändert. :)
Update sollte morgen verfügbar sein.
Grüße
Stephan
Alles klar - dank Dir! :)
Gibt es eigentlich bei euch Erfahrungen mit Werte- Ausreißern? Wenn sich bei mir die Zisterne füllt (plätschert von oben rein) und leert (Wasseroberfläche völlig ruhig) habe ich Ausreißer (siehe Screenshot). Sind die bei dem System normal?
Gruß
Frank
Hi
Ja, das habe ich auch immer mal wieder.
@Stephan:
Könntest Du eine Überprüfung einbauen, dass Werte ignoriert werden, die größer der max. Kapazität sind? Also
RemainingUsableLevel > TotalUsableCapacity = "Reading verwerfen"
Ich denke, das müsste einen Großteil der unsinnigen Werte verhindern. Was meinst Du dazu?
Gruß,
Frank
Hallo,
wenn die Ausreißer immer größer TotalUsableCapacity sind würde das "Reading verwerfen" gehen. Dann sind die Werte aber sinnlos und eher ein Bug in der Firmware des EcoMeters. Die Information würde ich dann gerne so an den Hersteller geben.
Grüße
Stephan
Solche Ausreisser kommen bei mir auch immer wieder vor.
Was dabei noch auffällt ist das das Ganze damit anfängt das permanent Werte eingelesen werden was nicht notwendig ist, da sich das Niveau gar nicht geändert hat.
Anbei ein LOG wo das wunderschön ersichtlich ist, und auch Werte (Ausreiser) entstehen die ea gar nicht geben kann.
Hier mal meine Übergangslösung gegen die Ausreißer:
Attr userReading zum Modul:
content {tek603_filter($name)}
In die MyUtils:
sub tek603_filter($) {
my ($tek603_name) = @_;
my $lev = ReadingsNum("$tek603_name","RemainingUsableLevel",0);
my $cap = ReadingsNum("$tek603_name","TotalUsableCapacity",0);
if (($lev - 300) <= $cap) {
return sprintf "%.1f",$lev*0.001
}
}
Das "- 300" ist ein individueller Offset der bewirkt, dass ein geringfügiges Überfüllen auch noch gemessen wird.
Das userReading "content" wird dann in einem ReadingsProxy weiterverarztet:
define Sens_L_Zisterne readingsProxy Zisterne_Ecometer:content
attr Sens_L_Zisterne event-min-interval content:300
attr Sens_L_Zisterne event-on-change-reading content:0.5
attr Sens_L_Zisterne stateFormat Inhalt: content m³
attr Sens_L_Zisterne userReadings content {ReadingsNum("Zisterne_Ecometer","content",0)}
Geloggt wird das Reading "content" des readingsProxy (hier "Sens_L_Zisterne") .
Edit: Nach langem Probieren und immer wieder Commandref + Wiki lesen, bin ich nun mit dem Verhalten bei "Schnellfeuer" des Sensors zufrieden. Eigentlich könnte man das event-on-change-reading sogar noch komplett weg lassen. Wichtig ist das zusätzliche Reading (content) im readingsProxy, welches sich nun per event-min-interval wunschgemäß bändigen lässt.
Hallo,
ich versuche auch gerade, mein Ecometer an FHEM anzubinden. Ärgerlicherweise werden mir aber bis auf den Status keinerlei Readings angezeigt (siehe angehängtes Bild).
Damit das Modul lief habe ich noch ein Paket nachinstalliert:
aptitude install libdigest-crc-perl
demesg ergab:
root@raspberrypi:/opt/fhem/log# dmesg | grep cp210x
[21248947.470461] usbcore: registered new interface driver cp210x
[21248947.470641] usbserial: USB Serial support registered for cp210x
[21248947.470798] cp210x 1-1.2:1.0: cp210x converter detected
[21248947.471562] usb 1-1.2: cp210x converter now attached to ttyUSB0
Daher habe ich den Sensor mit
define Niveausensor TEK603 /dev/ttyUSB0
angelegt.
Was könnte ich vergessen haben?
Vielen Dank für Eure Hilfe!
Nach spätestens einer Stunde sollen Readings angezeigt werden.
alternativ kann man auch den Sensor und den Monitor neu pairen.
Nach der Paarung der Geräte sendet der Sensor für ungefähr 10 Minuten kontinuierlich
Daten zum Proteus Monitor (Echtzeitmodus) und damit auch zum FHEM.
Nee, leider tauchten bis jetzt keine Readings auf.
Ich habe extra mal den Rasen gesprengt, damit sich mal ein paar Werte ändern. Auf dem Display des Ecometers wird der neue Wert angezeigt, der Ecometer hängt nach wie vor per USB am Raspberry.
In FHEM ist beim Sensor nur ein Buffer hinzugekommen (siehe beiliegender Screenshot)
Nur zur Info, mein Problem mit den fehlenden Readings konnte ich durch eine Neuinstallation des FHEM-Servers lösen.
Nun bekomme ich in verschiedenen Abständen die Werte vom Ecometer. Mal nach 1 Stunde manchmal nach erst nach 3 Stunden. Ist das normal? Eigentlich sollte ja alle 30 Mnuten eine Messung übertragen werden. Habe ich vielleicht schlechten Empfang?
Freut mich das das Readings Problem gelöst ist. Meine Befürchtung der Hersteller hat was am Protokoll geändert hat sich zum Glück nicht bestätigt.
Wenn der Ecometer die passende Firmware für Zisternen hat schickt der Sensor in Intervallen von 30 Minuten Messdaten zur Funkstation. Er misst sogar in Echtzeit, sobald eine Füllstandsänderung von ≥3cm/min erfasst wird.
Schlechter Empfang könnte eine Ursache sein.
Der Ecometer wurde gleich mit der neuesten Fimware für Wasserzisternen ausgeliefert 👍. Nur um sicher zu gehen: Wenn der Empfang gut wäre, dann dürfte der Zeitstempel hinter den Messungen nie älter als 30 Minuten sein? Falls das so ist sollte ich wohl auf dem Ecometer S plus umsteigen.
Einfach vorher mal testen indem man Sender und Empfänger näher zusammen bringt. Sollte das Erfolgreich sein kann Ecometer S plus ein Lösung für das Problem sein.
Habe ein brandneues Proteus EcoMeter, bekomme aber keine Daten. Am Monitor werden sie aber angezeigt:
Internals:
CFGFN
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
FD 75
NAME TEK603
NR 348
PARTIAL
PORTSTATE open
STATE open
TYPE TEK603
buffer 534900160210170e043c3c3c3c0000000d540f40f964
Readings:
2016-11-24 21:54:27 state opened
Attributes:
room Keller,Test
kann mir jemand einen Tipp geben?
Das hatte ich auch am Anfang: Der Ecometer zeigte Werte an, nur FHEM zeige nix. Bei mir lag es offensichtlich trotzdem an schlechtem Empfang. Versuche mal, die Position der Anzeige zu ändern. Bei mir hat das geholfen, auch wenn ich trotzdem immernoch für Stunden andere Werte auf der Anzeige habe als in FHEM.
ok - danke.
Nach nun fast 24h zeigt er Werte - seltsam.
Habe eine Frage zu den empfangenen Daten die irgendwie nicht zusammen passen.
RemainingUsableLevel 1410 2017-04-06 20:04:15
RemainingUsablePercent 78.8 2017-04-06 20:04:16
RemainingUsablem3psec 1269 2017-04-06 20:04:16
Temperature 8.33 2017-04-06 20:04:15
Time 19:56:14 2017-04-06 20:04:15
TotalUsableCapacity 1790 2017-04-06 20:04:16
Ullage 53 2017-04-06 20:04:15
Wenn ich jetzt den aktuellen Füllstand nehme (RemainingUsableLevel 1410) und diesen vom Messbereich abziehe (TotalUsableCapacity 1790) sollte der verbleibende obere Leerraum 380 eigentlich ergeben.
Tatsächlich ist die Ausgabe (Ullage 53) viel kleiner.
Woran liegt das. FHEM Fehler oder TEK603 Fehler.
Nichts von Beidem, es ist ein Verständnisfehler. Ullage ist der Abstand zwischen dem aktuellen Wasserpegel und dem Messgerät in cm. Die Werte von RemainingUsableLevel und TotalUsableCapacity sind in Liter.
Danke für den Hinweis.
Funktioniert das Modul auch mit dem Simka Tankalert Eco Oil (Plus) ? Es scheint sich ja um ein baugleiches Gerät zu handeln.
Der Simka Tankalert Eco Oil scheint keine USB Schnittstelle zu haben.
Deshalb funktioniert er leider nicht mit dem TEK603 Modul.
Grüße
Stephan
Hier (http://www.wr-oeltechnik.de/downloads/benutzerhandbuch-tankalert-eco-oil.pdf) auf Seite 2 ist ein USB- Stecker zu sehen. Vermutlich ist es das gleiche System, nur der Anbieter erwähnt die Möglichkeit nicht, um den Support nicht an der Backe zu haben.
Edit: Vielleicht wäre es ganz sinnvoll hier, oder im Wiki mal alle baugleichen Systeme zusammenzuschreiben. Von denen soll es ja mehrere geben und vielleicht kommt man so an bessere Preise.
Meine Fundstellen:
- Proteus Ecometer (https://www.e-sensorix.com/de/fuellstandsanzeige)
- Secu-Tech Apollo (http://www.xn--fllstand-65a.at/de/F%C3%BCllstandsanzeige/Ultraschall/Funk/Tankdaten)
- Simka Tankalert (http://www.simka.de/produkt/tankalert-eco-oil)
- Watchman Sonic (https://www.kingspanenviro.com/sensor/watchman-sonic-oil-level-monitor)
- Tek-603 (http://fuelminder.biz/secu-tech/tek-603.html)
wenn doch eine USB Schnittstelle vorhanden ist, dann einfach testen. Die Chancen sind dann ganz gut des es ein TEK603 ist und funktioniert.
Grüße
Stephan
Hi @ll,
der Sensor läuft und brachte anfangs keine fehler
jetzt sehe ich im log
2017.11.03 06:38:18 1: PERL WARNING: substr outside of string at ./FHEM/44_TEK603.pm line 164.
2017.11.03 06:38:18 1: PERL WARNING: Use of uninitialized value $crc in string ne at ./FHEM/44_TEK603.pm line 169.
2017.11.03 06:38:18 1: PERL WARNING: substr outside of string at ./FHEM/44_TEK603.pm line 159.
2017.11.03 06:38:18 1: PERL WARNING: Use of uninitialized value in hex at ./FHEM/44_TEK603.pm line 159.
2017.11.03 06:38:18 1: PERL WARNING: substr outside of string at ./FHEM/44_TEK603.pm line 163.
kann mir da einer weiterhelfen ?
info:
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
FD 82
NAME ecometer
NR 1196
PARTIAL
PORTSTATE open
STATE opened
TYPE TEK603
buffer 5349001602100b0904e75dde6200000010b71cbde266
READINGS:
2017-11-03 09:38:24 RemainingUsableLevel 4279
2017-11-03 09:38:24 RemainingUsablePercent 58.2
2017-11-03 09:38:24 Temperature 18.89
2017-11-03 09:38:24 Time 10:39:03
2017-11-03 09:38:24 TotalUsableCapacity 7357
2017-11-03 09:38:24 Ullage 69
2017-11-02 10:35:41 state opened
Attributes:
room Heizöl
mfg. m
Fehler kann ich fixen.
Ursache dafür könnte schlechter Empfang oder schwache Batterie des Sensors sein.
Grüße
Stephan
Hi Stephan,
ZitatUrsache dafür könnte schlechter Empfang oder schwache Batterie des Sensors sein.
Batterie ist neu, Empfang hat sich nicht geändert :o
die Fehler sind neu (ca. 2 Tag alt) :(
mfg. m
wie oft stehen die Fehler im Log?
Grüße
Stephan
Hi Stephan,
gestern and heute das erste mal
2017.11.02 04:07:46 1: PERL WARNING: substr outside of string at ./FHEM/44_TEK603.pm line 159.
2017.11.02 04:07:46 1: PERL WARNING: Use of uninitialized value in hex at ./FHEM/44_TEK603.pm line 159.
2017.11.02 04:07:46 1: PERL WARNING: substr outside of string at ./FHEM/44_TEK603.pm line 163.
2017.11.02 04:07:46 1: PERL WARNING: substr outside of string at ./FHEM/44_TEK603.pm line 164.
2017.11.02 04:07:46 1: PERL WARNING: Use of uninitialized value $crc in string ne at ./FHEM/44_TEK603.pm line 169.
2017.11.03 06:38:18 1: PERL WARNING: substr outside of string at ./FHEM/44_TEK603.pm line 164.
2017.11.03 06:38:18 1: PERL WARNING: Use of uninitialized value $crc in string ne at ./FHEM/44_TEK603.pm line 169.
2017.11.03 06:38:18 1: PERL WARNING: substr outside of string at ./FHEM/44_TEK603.pm line 159.
2017.11.03 06:38:18 1: PERL WARNING: Use of uninitialized value in hex at ./FHEM/44_TEK603.pm line 159.
2017.11.03 06:38:18 1: PERL WARNING: substr outside of string at ./FHEM/44_TEK603.pm line 163.
mfg. m
Danke! :)
Hallo,
kann der TEK603 auch per ser2net also via IP an FHEM angebunden werden?
Hintergrund ist meine Installation. FHEM läuft auf einem ESXi. Ich habe 2 HMLAN, einen CUNO und via ser2net einen CUL und einen ZWAVE Stick angebunden.
Hier meine ser2net.conf auf dem PI:
3333:raw:0:/dev/ttyACM0:38400 8DATABITS NONE 1STOPBIT
4444:raw:0:/dev/ttyACM1:115200 8DATABITS NONE 1STOPBIT
Und hier meine FHEM cfg:
#########################################################################
## CUL Start
#########################################################################
define CUL_PI CUL 10.0.0.203:3333 0000
attr CUL_PI devStateIcon Initialized:usb@green disconnected:usb@red
attr CUL_PI group Zentrale
attr CUL_PI icon cul_868
attr CUL_PI room 99.System
#########################################################################
## CUL Ende
#########################################################################
#########################################################################
## ZWAVE Start
#########################################################################
define ZWAVE_PI ZWDongle 10.0.0.203:4444
attr ZWAVE_PI devStateIcon Initialized:usb@green Open:usb@red
attr ZWAVE_PI group Zentrale
attr ZWAVE_PI homeId cf3eca74
attr ZWAVE_PI icon cul_868
attr ZWAVE_PI room 99.System
#########################################################################
## ZWAVE Ende
#########################################################################
Jetzt würde ich gerne den TEK603 dazuhängen.
Geht das?
Hat jemand Erfahrung damit?
Geht leider nicht.
Habe erstmal ein lokales FHEm installiert und übernehme dann mit Fhem2Fhem...
Hallo eisler,
vielen Dank für das Modul. Am Slave raspi läuft es gut.
Kann das Modul fhem2fhem im raw-Modus?
Am Besten für mich wäre eine Anbindung via ser2net, aber fhem2fhem im raw-Modus wäre ja genauso.
Ich habe es folgendermassen definiert:
Am Slave:
define heizoel TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
attr heizoel room 01.Heizöl
define FileLog_heizoel FileLog ./log/heizoel-%Y.log heizoel.*
attr FileLog_heizoel room Log
Am Master:
define heizoelpi FHEM2FHEM 10.0.0.232:7072 RAW:heizoel
define heizoel TEK603 none
attr heizoel dummy 1
attr heizoel room 01.Heizöl
define FileLog_heizoel FileLog ./log/heizoel-%Y.log heizoel.*
attr FileLog_heizoel room Log
Ich habe irgendwie nur einen Wert übergeben bekommen.
Hallo möchte gerne den Wasserstand auch via homebridge (Apple HomeKit) sehen. Hat da jemand Erfahrung? Wollte deshalb von Domoticz zu FHEM wechseln, auch wegen der tollen deutschen Community hier...
so habe das Modul drin, wie bekomme ich es jetzt hin das mir die Prozent in Homebridge angezeigt werden. Ich muss hierzu den Bereich in Prozent als Luftdruck Geräte jonfigurieren stehe da aber auf dem Schlauch...
Das sagt das Plugin
attr <tempHum> genericDeviceType thermometer
attr <tempHum> homebridgeMapping [CurrentTemperature=temperature1] CurrentRelativeHumidity=<device2>:humidity
Ich habe mir den Sensor jetzt auch zugelegt. Aber ich werde ums Verrecken nicht schlau aus dem Ding.
Ich habe einen rechteckigen Heizöltank mit einer Grundfläche von 290 x 145 cm. Die Füllhöhe beträgt 115 cm. Maximalfüllvolumen ca. 4800 Liter. Der Sensor unterschlägt mir jedoch locker 500 Liter.
Ich habe bereits die Firmware Version 29 draufgepackt, das untere Offset auf 0 und das obere auf 5 cm gestellt.
Die von mir eingestellten 4800 Liter Maximalvolumen werden im Monitor zwar angezeigt, in FHEM jedoch nur 4466. Ich vermute mal, dass TotalUsableCapacity dieser Wert sein soll. Laut Zollstockmessung (48 cm) müssten noch etwas über 2000 Liter im Tank sein. Angezeigt werden mir jedoch nur 1503 (im Monitor und in FHEM).
Wäre es möglich, dass der Sensor einen Knacks hat?
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
FD 24
NAME heizoelstand
NR 771
PARTIAL
PORTSTATE open
STATE opened
TYPE TEK603
buffer 53490016021013182a0000028971004705df1172e36c53490016021013182b0000028971004705df1172e01953490016021013182b0000028971004705df1172e01953490016021013182c0000028971004705df1172e852
READINGS:
2018-04-10 19:26:01 RemainingUsableLevel 1503
2018-04-10 19:26:01 RemainingUsablePercent 33.7
2018-04-10 19:26:01 Temperature 22.78
2018-04-10 19:26:01 Time 19:24:42
2018-04-10 19:26:01 TotalUsableCapacity 4466
2018-04-10 19:26:01 Ullage 71
2018-04-10 19:15:11 state opened
Attributes:
Oli
EDIT: Ach ja, ich habe schon alle möglichen Positionen auf der Tankoberfläche ausprobiert, auf die Gefahr hin, dass der Messstutzen zu nach an der Wandung ist. Jedoch ohne nennenswerte Änderung der Ergebnisse.
Hallo Oli,
werden die werde nach nach dem Anlernen im Echtzeit-Modus korrekt in FHEM angezeigt?
Grüße
Stephan
Zitat von: OliS. am 10 April 2018, 19:32:11
Ich habe mir den Sensor jetzt auch zugelegt. Aber ich werde ums Verrecken nicht schlau aus dem Ding.
Das ging/geht mir ähnlich, wobei ich mich dann dazu entschlossen habe nicht mit Offset-Werten etc. herumzuspielen und mit dem zu niedrig angezeigten Wert als "Sicherheitsreserve" zu leben.
Zitat von: OliS. am 10 April 2018, 19:32:11
Ich habe einen rechteckigen Heizöltank mit einer Grundfläche von 290 x 145 cm. Die Füllhöhe beträgt 115 cm. Maximalfüllvolumen ca. 4800 Liter. Der Sensor unterschlägt mir jedoch locker 500 Liter.
Ich habe bereits die Firmware Version 29 draufgepackt, das untere Offset auf 0 und das obere auf 5 cm gestellt.
Die von mir eingestellten 4800 Liter Maximalvolumen werden im Monitor zwar angezeigt, in FHEM jedoch nur 4466. Ich vermute mal, dass TotalUsableCapacity dieser Wert sein soll. Laut Zollstockmessung (48 cm) müssten noch etwas über 2000 Liter im Tank sein. Angezeigt werden mir jedoch nur 1503 (im Monitor und in FHEM).
Ich nehme an, dass Deine Maße die Außenabmessungen und das Bruttovolumen vom Typenschild sind. Für die Innenabmessungen kannst Du in jeder Richtung 1-2 Zentimeter abziehen. Falls Du einen doppelwandigen Tank, dann dürfen es eher 5 Zentimeter sein.
Für Deine Situation entspricht 1cm ~ 41,73 Liter (4800 geteilt durch 115). Durch die 5 Zentimeter Offset hast Du schon ca. 200 Liter Abweichung
Zitat von: OliS. am 10 April 2018, 19:32:11
Wäre es möglich, dass der Sensor einen Knacks hat?
Das glaube ich eher nicht. Hast Du bei proteus-meter.com gekauft? Der Support dort antwortet erfahrungsgemäß schnell und umfangreich
Der Sensor unterstellt einen nicht nutzbaren Totraum am Boden des Tanks.
Ich habe einen 10.000 Liter-Tank und ein Totraum von 8 cm (entspricht 533 l).
TotalUsableCapacity ist bei mir demnach 9.467 l.
Guten Morgen und danke Euch allen für die zahlreichen Antworten.
Zitatwerden die werde nach nach dem Anlernen im Echtzeit-Modus korrekt in FHEM angezeigt?
Die Werte werden auch im Echtzeitmodus nicht korrekt angezeigt.
ZitatDer Sensor unterstellt einen nicht nutzbaren Totraum am Boden des Tanks.
Den voreingestellten Totraum habe ich ja schon über die Einstellungen mit der Konfigurations-Software eliminiert. Das untere Offset steht bei mir auf 0. Bei den Maßen meines Tanks wären das bei einem Offset von 8 cm auch bloß 342 Liter.
ZitatIch nehme an, dass Deine Maße die Außenabmessungen und das Bruttovolumen vom Typenschild sind. Für die Innenabmessungen kannst Du in jeder Richtung 1-2 Zentimeter abziehen. Falls Du einen doppelwandigen Tank, dann dürfen es eher 5 Zentimeter sein.
Nein, das sind die von mir gemessenen Innenmaße des Tanks.
ZitatHast Du bei proteus-meter.com gekauft? Der Support dort antwortet erfahrungsgemäß schnell und umfangreich
Ja, habe ich. Ich werde denen mal schreiben.
Oli
Jetzt läuft es bei mir.
Problem war wohl meine alte Windows-Möhre. Die hat die Einstellungen der Offset-Werte nicht korrekt auf dem Monitor gespeichert. Jetzt bekomme ich auch plausible Werte angezeigt.
Danke für das schöne Modul. Jetzt muss ich nicht mehr jeden Monat meinen Zollstock in den Tank stippen.
Jetzt muss ich nur noch einen Weg finden, wie die Monatsverbräuche automatisch in einer Excel-Tabelle landen. Aber das ist ein anderes Thema.
Oli
Ich hab' da mal 'ne Frage ;)
Das Modul funktioniert bei mir einwandfrei.
Wäre es möglich, das Attribut "stateFormat" mit einzubauen?
Dann hätte ich schneller eine Überblick 8)
Hallo,
ich habe das Modul modifiziert um auch event-on-change-reading zu Unterstützen. Ich habe lediglich die AttrList geändert in
$hash->{AttrList} = 'do_not_notify:0,1 dummy:1,0 loglevel:0,1,2,3,4,5,6 '
.$readingFnAttributes;
Hallo Johnnyflash,
danke. Ist jetzt im fhem repository: https://svn.fhem.de/trac/changeset/17651/
Grüße
Stephan
Hallo,
zwar bin ich hier im FHEM-Forum nicht ganz richtig, da ich eine Homematic CCU2 nutze. Mein Problem ist jedoch recht allgemein, so dass ich trotzdem mal nachfrage:
den Monitor habe ich über USB als ttyUSB0 eingebunden:
20:22:09 [ttyUSB0] *** connect(115200:8N1) CP2102 USB to UART Bridge Controller
USB 1-1.2 - {SONIC} CP2102 USB to UART Bridge Controller [FF] - /dev/ttyUSB0 {:202s} - connected
Nun hätte ich erwartet, dass alle 30min ein Datenstrom empfangen wird, der in einem Terminal angezeigt werden kann.
Dies ist jedoch nicht der Fall, auch nach Stunden / Reboot etc. etc. kommen keine Werte an.
Muss vorher eine Initialisierungssequenz an den Proteus Monitor gesendet werden, oder sollte das von alleine gehen?
Eine Initialisierungssequenz ist nicht notwendig.
EcoMeter für Heizöl liefert alle 60 Minuten einen Messwert.
EcoMeter Zisterne alle 30 Minuten.
In den ersten 10 Minuten nach dem Anlernen jede Sekunde.
Grüße
Stephan
Danke. So hatte ich es erwartet, als Wassersensor für die Zisterne sollte der TeK603 alle30min (oder manchmal auch länger) seine Daten senden.
Da mir die Baudrate unbekannt ist, habe ich mt verschiedenen Baudraten 4800 / 9600 /38400 / 115200 Baud jeweils mehrere Stunden getestet (der Wasserpegel ändert sich derzeit nur minimal - Nieselregen) , bekomme aber keine Daten in Empfangsrichtung angezeigt. Gibt es sonstige Voraussetzungen für den Empfang von Daten, die ich nicht beachtet habe?
Restliche Parameter für die serielle Schnittstelle: 8N1, keine Flußsteuerung.
115200 8N1 passt.
Voraussetzung ist das die Basisstation Daten vom Sensor empfängt, die werden dann auch via USB zur verfügung gestellt.
Grüße
Stephan
Das ist auch erfüllt, der Sensor ist mit der Basisstation gekoppelt, der Pegelstand hat sich über Nacht leicht erhöht und wird im Monitor angezeigt.
Steck das Teil doch mal ans Laptop und beobachte dort das Terminal.
Falls das geht könntest du noch eine Weile mit dem Treiber und der Schnittstellenkonfig spielen,
aber letztendlich wäre der wohl der Wechsel zur CCU3 oder Raspberrymatic zu überlegen.
Hallo
super Modul, es hat auf Anhieb funktioniert.. Herzlichen Dank dafür... Wo ich mich aber etwas schwer tue, ist mit der Konfiguration des Eco Meter S (Proteus) für meine Regenwassertonne.
Mein Betonregenwassertank liegt unter der Garage und hat folgende Innenmasse:
Breite: 3.2m
Tiefe: 2.3m
Höhe: 2m, wovon eine Maximalhöhe von 1.65m erlangt werden kann. Alles darüber fliesst in die Kanalisation.
Die Proteus-Rakete habe ich auf 1.80m (1.65 +15cm) montiert.
Siehe auch Handbild anbei.
Wenn ich also richtig rechne, hab ich ein Fassungsvolumen von 12.144liter. 1cm Wasserhöhe entspricht also knapp 74liter.
Wenn ich nun also im Eco Meter 12.144 Liter, 165cm Höhe, Offset 15cm, Boden 0cm eingebe, erhalte ich eine aktuelle Wasserhöhe von 1.55cm. Effektiv (mit Massstab gemessen) habe ich aber 160cm. 5cm macht rund 370liter aus. Wo ist da die Diskrepanz? Oder muss ich irgendwo was anderes eingeben?
Danke für die Hilfe.
Lg C
EDIT: Ich habe nochmals alles von vorne konfiguriert. Jetzt gehts prima..
Guten Nachmittag,
ich kriege in regelmässigen Abständen folgende Fehlermeldungen mit meinem Proteus bei meinem Regenwassertank:
[Sun Apr 7 03:50:39 2019] fhem.pl: substr outside of string at ./FHEM/44_TEK603.pm line 160.
[Sun Apr 7 03:50:39 2019] fhem.pl: Use of uninitialized value in hex at ./FHEM/44_TEK603.pm line 160.
[Sun Apr 7 03:50:39 2019] fhem.pl: substr outside of string at ./FHEM/44_TEK603.pm line 164.
[Sun Apr 7 03:50:39 2019] fhem.pl: substr outside of string at ./FHEM/44_TEK603.pm line 165.
[Sun Apr 7 03:50:39 2019] fhem.pl: Use of uninitialized value $crc in string ne at ./FHEM/44_TEK603.pm line 170.
[Sun Apr 7 03:50:39 2019] fhem.pl: substr outside of string at ./FHEM/44_TEK603.pm line 165.
[Sun Apr 7 03:50:39 2019] fhem.pl: Use of uninitialized value $crc in string ne at ./FHEM/44_TEK603.pm line 170.
Die Zeilen 160-170 im 44_TEK603.pm sind wie folgt.
my $time = sprintf '%02d:%02d:%02d', hex(substr($hash->{buffer},12,2)), hex(substr($hash->{buffer},14,2)), hex(substr($hash->{buffer},16,2));
#my $epromStart = hex(substr($hash->{buffer},18,4));
#my $epromEnd = hex(substr($hash->{buffer},22,4));
my $payloadlenght = $lenght - 26 - 4;
my $payload = substr($hash->{buffer},26,$payloadlenght);
my $crc = substr($hash->{buffer},26 + $payloadlenght,4);
my $ctx = Digest::CRC->new(width=>16, init=>0x0, poly=>0x1021, refout=>0, xorout=>0);
$ctx->add(pack 'H*',(substr($hash->{buffer},0,26 + $payloadlenght)));
my $digest = $ctx->hexdigest;
return '' if($crc ne $digest);
woran könnte das liegen? oder kann ich das getrost ignorieren?
Dann verstehe ich Ullage auch nicht. Gemäss Wiki ist das der Ölpegel. Bei mir steht nun 39 bei 10456l .. Was sind nun diese 39??
danke für die Antworten.
Lg c
Hallo choetzu,
sieht aus als wenn der Proteus was unbekanntes sendet, kannst du bitte
ab Zeile 156 folgendes mit einbauen und mir dann das Logfile zukommen lassen.
Log3 $name, 5, $hash->{buffer};
Ullage ist der vertikalen Abstand zwischen der Oberfläche der Flüssigkeit in dem Tank und dem Tanksensor.
Grüße
Stephan
Ich hab mal am Modul etwas rumgepatcht, damit die Verbindung auch via ser2net funktioniert. Ich hoffe direkt angeklemmt funktionierts weiterhin...
Für ser2net einfach folgenden Eintrag erstellen in der Config:
23001:raw:0:/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0:115200 8DATABITS NONE 1STOPBIT
und dann bei fhem
define Zisterne TEK603 hostname:23001
Port darf natürlich auch was anderes als 23001 sein.
ser2net patch mit eingebaut: https://svn.fhem.de/trac/changeset/19936/trunk/fhem
Grüße
Stephan
Hallo Stephan,
weißt du wie man eine Sub wie die "TEK603_reconnect($)" von der FHEM- Eingabezeile aus aufrufen kann?
Was müsste übergeben werden, damit das Reconnect ausgeführt wird? Bzw. wäre es möglich ein
"set <name> reopen" einzubauen?
Bei mir hängt sich die Schnittstelle öfter mal auf und ich bekomme keine Daten mehr, obwohl der Empfänger
aktuelle Daten hat. Wenn ich das Modul dann redefiniere kommen die Daten wieder. Somit sollte die Schnittstelle
unter Linux nicht gehangen haben, sondern das Problem innerhalb FHEM liegen.
Ich würde also gern automatisiert ein "Reconnect" bzw. "Reopen" ausführen.
Gruß
Frank
Edit: Konnte es jetzt selbst lösen: Man definiert ein at, welches ein Mal am Tag einfach die DEF des Moduls wiederholt.
Damit wird das Modul redifined und verbindet sich erneut mit der Schnittstelle.
Hier gab es wieder einen Hänger (zu erkennen an "addLog") und um 1:00Uhr hat das at den Datenfluss wiederbelebt:
2020-06-20_07:19:29 Sens_L_Zisterne content: 2.1
2020-06-20_07:50:47 Sens_L_Zisterne content: 2.1
2020-06-20_08:22:05 Sens_L_Zisterne content: 2.1
2020-06-20_09:21:15 Sens_L_Zisterne content: 2.1 << addLog
2020-06-20_12:21:16 Sens_L_Zisterne content: 2.1 << addLog
2020-06-20_15:21:15 Sens_L_Zisterne content: 2.1 << addLog
2020-06-20_18:21:16 Sens_L_Zisterne content: 2.1 << addLog
2020-06-20_21:21:15 Sens_L_Zisterne content: 2.1 << addLog
2020-06-20_23:59:00 Sens_L_Zisterne content: 2.1 << addLog
2020-06-21_00:01:00 Sens_L_Zisterne content: 2.1 << addLog
2020-06-21_00:21:16 Sens_L_Zisterne content: 2.1 << addLog
2020-06-21_01:00:00 Sens_L_Zisterne content: 2.1
2020-06-21_01:27:16 Sens_L_Zisterne content: 2.2
2020-06-21_01:58:32 Sens_L_Zisterne content: 2.2
2020-06-21_02:29:49 Sens_L_Zisterne content: 2.2
2020-06-21_03:01:05 Sens_L_Zisterne content: 2.2
Hallo Frank,
ein patch könnte ich mit einbauen, für mehr fehlt gerade die Zeit.
Grüße
Stephan
Guten Tag,
ich habe das Modul erfolgreich am Laufen... Jedoch wenn ich den USB Stick nicht eingesteckt habe, startet FHEM gar nicht erst und folgende Nachricht wird geloggt.
Ich kann das device auch nicht disablen... Es bleibt nur die Deinstallation des Moduls.. Was ich nicht sehr sexy finde.. Gibts eine andere Möglichkeit?
ZitatSoftware error:
Can't call method "status" on an undefined value at ./FHEM/44_TEK603.pm line 147.
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.
[Sat Feb 29 09:29:05 2020] fhem.pl: Can't call method "status" on an undefined value at ./FHEM/44_TEK603.pm line 147.
ich schau mal was ich machen kann.
Grüße
Stephan
Hallo choetzu,
Attribute: disabled hinzugefügt.
Grüße
Stephan
Hallo Stephan,
ich würde noch mal gerne auf das Thema mit dem FHEM-Restart zurück kommen, dass choetzu auch schon bemerkt hat.
Wenn ich mein FHEM auf der Integration-Test-Maschine testen möchte, habe ich dort nur entweder gar kein USB-Device (oder nur einen Link auf /dev/zero o.ä.) und es würde schon reichen, wenn der Aufruf von $po->status() z.B. in einem eval-Block aufgefangen würde oder nur auf $po zu prüfen. Ich hatte das mal bei mir gemacht, aber das Device versucht hartnäckig, den Status zu lesen. Wäre schön, wenn das Device irgendwann merkt dass es partout keine Daten bekommt und dann auch damit aufhört.
Davon abgesehen macht es einen Integrationstest natürlich schwierig, wenn man dann je nach Umgebung Attribute setzen muss (und FHEM keine Conditionals darin unterstützt).
Ich hatte die Hoffnung dass das dummy-Attribut irgendwas tut, aber .. nein, tut es nicht (ist auch nicht dokumentiert, bin nur zufällig drüber gestolpert).
So sieht meine TEK603_ready aus (ohne den nutzlosen Prototypen):
sub TEK603_ready() {
my ($hash) = @_;
my $name = $hash->{NAME};
return if (IsDisabled($name));
return DevIo_OpenDev($hash, 1, 'TEK603_doInit') if($hash->{STATE} eq 'disconnected');
# This is relevant for windows/USB only
my $po = $hash->{USBDev};
my ($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags);
if ($po) {
($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags) = $po->status;
return ($InBytes > 0);
}
Log3($name, 3, $ErrorFlags);
Log3($name, 3, q{Can't call $po->status});
return;
}
In $ErrorFlags ist nie etwas enthalten, btw.
2020.06.04 19:51:00.231 3: Can't call $po->status
2020.06.04 19:51:00.261 3: Can't call $po->status
2020.06.04 19:51:00.262 3: Can't call $po->status
2020.06.04 19:51:00.268 3: Can't call $po->status
2020.06.04 19:51:00.682 3: Can't call $po->status
2020.06.04 19:51:00.754 3: Can't call $po->status
2020.06.04 19:51:00.755 3: Can't call $po->status
2020.06.04 19:51:01.109 3: Can't call $po->status
2020.06.04 19:51:01.174 3: Can't call $po->status
2020.06.04 19:51:01.175 3: Can't call $po->status
2020.06.04 19:51:01.199 3: Can't call $po->status
2020.06.04 19:51:01.200 3: Can't call $po->status
2020.06.04 19:51:01.227 3: Can't call $po->status
2020.06.04 19:51:01.234 3: Can't call $po->status
2020.06.04 19:51:01.397 3: Can't call $po->status
2020.06.04 19:51:01.398 3: Can't call $po->status
2020.06.04 19:51:01.594 3: Can't call $po->status
2020.06.04 19:51:01.714 3: Can't call $po->status
2020.06.04 19:51:01.715 3: Can't call $po->status
2020.06.04 19:51:02.240 3: Can't call $po->status
Ich war eben mal mutig und hab den Empfänger meiner Proteus-Rakete gezogen - gleiches Bild im Live-Betrieb, wenn das USB-Device plötzlich weg ist. Hat mein FHEM auch ganz gut ausgelastet, ein Restart funktioniert dann auch nicht mehr :-(
Hallo Christoph,
da ich gerade keinen zugriff auf ein Testsetup habe kann ich das leider nicht nachstellen.
Sollte bei deinen Tests ein Patch für das Modul herauskommen kann ich den gerne übernehmen.
Grüße
Stephan
Hi,
schau mal hier: https://bitbucket.org/christoph-morrison/fhem-patches/src/master/FHEM/44_TEK603.pm/she2Aedai3.patch
done. https://svn.fhem.de/trac/changeset/22136/trunk/fhem
Grüße
Stephan
Hi,
Gibt es die Möglichkeit die Frequenz von alle 30min auf alle 15min oder alle 10min zu ändern?
Grund dafür ist, dass wenn ich mein Garten bewässere ändert sich der Füllstand definitiv mehr als 3cm/h aber er schaltet trotzdem nicht in den Echtzeitmodus. Alle 30min ist zu träge um die Frischwasser Zufuhr zu steuern damit die Zisterne nicht leer läuft.
Grüße
Philipp
Hallo Philipp,
meines Wissens ist der Wert nicht änderbar. Der ist fest in der Firmware des Gerätes. Deshalb gibt es auch Füllstandsanzeige für Heizöltanks mit Messdaten in 60min Intervallen und Füllstandsanzeige für Zisterne, Wassertanks mit 30min Intervallen.
Grüße
Stephan
Zitat von: Phili am 22 Juli 2020, 23:26:14
Gibt es die Möglichkeit die Frequenz von alle 30min auf alle 15min oder alle 10min zu ändern?
Grund dafür ist, dass wenn ich mein Garten bewässere ändert sich der Füllstand definitiv mehr als 3cm/h aber er schaltet trotzdem nicht in den Echtzeitmodus. Alle 30min ist zu träge um die Frischwasser Zufuhr zu steuern damit die Zisterne nicht leer läuft.
IMHO sind die Geräte für solch eine Überwachung nicht geeignet. Der Meldezyklus ist grundsätzlich zu lang um irgendwas punktgenau damit zu steuern. Für sowas brauchst du einen Schwimmerschalter als Sicherheitsmechanismus.
Danke Stephan und Christoph!
Guten Morgen,
ich habe seit über einem Jahr Eco Meter S (Proteus) erfolgreich am Laufen. Und er liefert auch zuverlässig an FHEM. Jedoch seit 30.7. kommen irgendwie keine Daten mehr rein. Ich habe nix geändert, war auch in den Ferien.
Nun habe ich alles geupdatet und ein Restart gemacht, dies vor 20 Std. Immer noch nix. Verbose 5. Auch nix, kommt einfach nix mehr an. Den UBS Stick wird angezeigt und auf dem Monitor werden die Werte (z.Z. Full) angezeigt.
Wie kann ich prüfen, ob TEK603 auch wirklich was empfängt? Oder wo könnte der Fehler liegen?
Lg C
Hallo choetzu,
Zum testen kann man den Sensor und den Monitor neu pairen.
Nach der Paarung der Geräte sendet der Sensor für ungefähr 10 Minuten kontinuierlich
Daten zum Proteus Monitor (Echtzeitmodus) und damit auch zum FHEM.
Grüße
Stephan
Zitat von: eisler am 05 August 2020, 12:50:32
Hallo choetzu,
Zum testen kann man den Sensor und den Monitor neu pairen.
Nach der Paarung der Geräte sendet der Sensor für ungefähr 10 Minuten kontinuierlich
Daten zum Proteus Monitor (Echtzeitmodus) und damit auch zum FHEM.
Grüße
Stephan
Danke. Meinst du mit "neu Pairen" ein neues Device TEK603 erstellen mit den selben USB-credentials?
kein neues TEK603 Device erstellen!
mit neu Pairen meine ich:
https://www.youtube.com/watch?v=zk2inZcjvkQ
Grüße
Stephan
... oder einfach eine Bewässerung starten. Wenn die Leveländerung groß genug ist, schaltet der Sender auch in den "Echtzeitmodus" bis das Level sich wieder beruhigt hat.
Bei mir hat sich das Modul regelmäßig aufgehängt und keine Daten mehr eingelesen. Nun erneuere ich ein mal täglich die Def. des Moduls per at- Befehl und habe so höchtens kürzere Ausfallzeiten, die ich per AddLog überbrücke damit der Trend durchläuft. Da du aber Neustarts gemacht hast (danach ging es bei mir immer wieder), scheint der Fall bei dir etwas anders zu liegen.
Mir sind nach einem Check aufgefallen das beim Start von FHEM folgende Meldung im LOG aufscheint.
PERL WARNING: Prototype mismatch: sub main::TEK603_ready ($) vs () at ./FHEM/44_TEK603.pm line 163, <$fh> line 186
Dieser LOG Eintrag ist mir früher nie aufgefallen.
Hat sich im Modul etwas geändert?
Daten werden jedenfalls übermittelt.
In Zeile 38 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/44_TEK603.pm#L38) müsste noch der vordeklarierte Prototyp weg (und bei allen anderen auch, Prototypen sind in dem Modul komplett nutzlos). Ich hatte in meinem Vorschlag von weiter oben TEK603_ready() entsprechend verändert.
ZitatIn Zeile 38 müsste noch der vordeklarierte Prototyp weg (und bei allen anderen auch,
Also Zeile 38 löschen, Änderung ab Zeile 141 laut deiner Erläuterung.
Wo die weitere vordeklarierte Prototyp Änderungen durchzuführen sind habe ich noch nicht verstanden?
Nach deiner Änderung tauchen dafür die nächsten Prototypen auf.
ZB
PERL WARNING: Prototype mismatch: sub main::TEK603_ready ($) vs () at ./FHEM/44_TEK603.pm line 159, <$fh> line 186.
Zitat von: Burny4600 am 15 August 2020, 18:46:36
Nach deiner Änderung tauchen dafür die nächsten Prototypen auf.
Genau die meinte ich. Lass das aber mal lieber Eisler offiziell machen.
kann ich mir gerne mal anschauen.
Grüße
Stephan
sollte jetzt keine Prototype mismatch warnings mehr geben.
https://svn.fhem.de/trac/changeset?reponame=&new=22613%40%2F&old=22612%40%2F
Grüße
Stephan
Ja, diese Meldungen sind weg.
Hallo zusammen,
mein Eco Meter S (Proteus) liefert wieder zuverlässig Daten. Herzlichen Dank für Eure Hilfen eisler und fidel.
Ich habe eine generelle Frage:
Da mein Betonwassertank unter der Garage ist, kann es vorkommen, dass sich durch die Temperaturschwankungen (v.a. im Herbst/Winter) zu Kondensbildung auf der Membrane (Rakete) kommen kann. Mit WDC40 kann ich das ganz gut im Griff haben. Aber gibt es doch mal Kondenswasser, dann liefert die Rakete einen FehlerCode. Ist es möglich, dass man diesen Fehlercode in ein Reading packen könnte? Oder dass zumindest ein Event ausgelöst wird?
So erkennt man (ohne aufs Display vom Proteus zu schauen) ob es einen Fehler gibt.
Was meint ihr? Oder wie handhabt ihr Fehlermeldungen?
Lg c
k
Zitat von: choetzu am 26 August 2020, 16:42:27
Hallo zusammen,
mein Eco Meter S (Proteus) liefert wieder zuverlässig Daten. Herzlichen Dank für Eure Hilfen eisler und fidel.
Ich habe eine generelle Frage:
Da mein Betonwassertank unter der Garage ist, kann es vorkommen, dass sich durch die Temperaturschwankungen (v.a. im Herbst/Winter) zu Kondensbildung auf der Membrane (Rakete) kommen kann. Mit WDC40 kann ich das ganz gut im Griff haben. Aber gibt es doch mal Kondenswasser, dann liefert die Rakete einen FehlerCode. Ist es möglich, dass man diesen Fehlercode in ein Reading packen könnte? Oder dass zumindest ein Event ausgelöst wird?
So erkennt man (ohne aufs Display vom Proteus zu schauen) ob es einen Fehler gibt.
Was meint ihr? Oder wie handhabt ihr Fehlermeldungen?
Lg c
würd mich riesig um eine Antwort freuen... ;) Danke.
falls ich den Fehlercode bekomme kann ich den auch in ein Reading packen.
Ich schau mal was ich machen kann.
Grüße
Stephan
Ich habe nachgeschaut alles was ich via serieller USB Schnittstelle bekomme gibts auch in FHEM als Readings. :) Leider kein Fehlercode. :(
Man hätte noch die Möglichkeit das EEPROM auszulesen also "Tank Shape","Tank Height",...,"Liquid Type" und zu beschreiben, falls jemand bedarf hat und das implementieren möchte kann ich gerne die Informationen zukommen lassen.
Grüße
Stephan
Hallo zusammen,
Ich habe mir jetzt auch einen gebrauchten ecometer besorgt. Leider scheint deren Tool nicht mehr zu laufen.
Wenn ich den Monitor an den PC anschließe kommt die Meldung "Error communicating with monitor".
Habe schon versucht neue Treiber zu finden, leider alles ohne Erfolg.
Gibt es mittlerweile die Möglichkeit die Offsets über fhem zu regeln?
Hallo,
Aktuelle Treiber gibt es hier: https://www.proteus-sensor.de/Hilfe-Infos#Universal-Software
Offsets über das fhem Modul zu regeln geht leider noch nicht. Mann könnte aber die
Offsets über die Readings anpassen.
Grüße
Stephan
Guten Abend,
seit 28.8. funktioniert mein Eco Meter S (Proteus) nicht mehr. Sprich, die Werte werden nicht aktualisiert obschon auf dem Monitor alles richtig angezeigt wird. Irgendwie kommen die Werte nicht über die USB Schnittstelle an.. Ich habe irgendwann mal ein Update/Upgrad (bullseye) gemacht. Könnte es daran liegen?
Lg c
Hi,
das Problem hatte ich auch: Regelmäßig ging die Verbindung verloren, das USB- Gerät unter Linux war aber ansprechbar.
Geholfen hat bisher nur ein ständig wiederholender redifine. Läuft bei mir seit Jahren so:
defmod Func_TEK603_Redefine_A at +*03:00:00 defmod Zisterne_Ecometer TEK603 /dev/serial/by-path/pci-0000:00:14.0-usb-0:2.2:1.0-port0
Gruß
Frank