• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
problem with alecto_wx500 protocol (pilight V7)
#1
I have a problem with the alecto_wx500 protocol (pilight v7.0).
if the Temperature goes under 0.00°C i get output of 204.7°C ...


Temp .. <-- binary --> .. dec. . pilight
+3.0 := 0000 0001 1110 =.. 30 . . . 3.0
+2.9 := 0000 0001 1101 =.. 29 . . . 2.9
+1.0 := 0000 0000 1010 =.. 10 . . . 1.0
+0.2 := 0000 0000 0010 =... 2 . . . 0.2
+0.1 := 0000 0000 0001 =... 1 . . . 0.1
+0.0 := 0000 0000 0000 =... 0 . . . 0.0
-0.1 := 1111 1111 1111 = 4096 . . 204.7
-0.2 := 1111 1111 1110 = 4094 . . 204.6
-1.0 := 1111 1111 0110 = 4086 . . 203.8
-1.1 := 1111 1111 0101 = 4085 . . 203.7
-2.0 := 1111 1110 1100 = 4076 . . 202.8


Sorry for the dots in the list. Just trying to align the data with the heading..

According to the this document "This 12 bits wide 2's complement signed binary number represents the actual temperature value in 0.1 °C units".

It looks like only 11 bits are used and there is no awareness of the negative numbers.. (flipping the bits and add one).

Can someone confirm this (and hopefully fix this for pilight v8.0!)?
 
Reply
#2
There should already be a fix in the development code.
 
Reply
#3
Also see this thread
 
Reply
#4
Thanks for pointing that out! My searching skills fail me again. Could that be my ageWink?
I guess I need to leave the v7.0 stable branche ..
Will dig into that.

... so, I now have installed the Nightly Build but the negative temperature problem still exists...
As we are heading towards the summer it will be a wile before the problem presents itself again Tongue
 
Reply
#5
Hi all,

I have cloned the development branche from github and compiled pilight (after some changes in the alecto_ws1700 protocol), but now my W044-sensor that uses the alecto_wx500 protocol does not work anymore... I had no problems with the nightly build from some weeks ago.

Also I see in the alecto_wx500.c source a constant/var "EPSILON" that is nowhere defined (that is, I cannot find it)...

Is there development in progress in the development-branche for this protocol??

Is there someone who can point me in the right direction?

Thanks!!

UPDATE:
Reinstalled the latest nightly (7.0.59-g6f3a679) and now my W044 (alecto_wx500) is seen by pilight again..
I probably do something wrong with compiling (use setup.sh) but have no idea Angry and now my changes in alecto_ws1700 are lost..
 
Reply
#6
Yes, I've had similar problems before when compiling pilight and having an apt version installed at the same time. What I usually end up doing is to completely uninstall the apt version, and then compile pilight like this:
Code:
cmake .
make -j5
without sudo make install. Then you can't run the wrong version by accident, the executables will be placed in the directory where you are compiling from. Then you can run them with (for examplesSmile
Code:
sudo ./pilight-daemon

I think there is a constants.h file (or something like that, not really sure) where EPSILON is defined as a constant.

There have been 2 changes to the alecto_wx500 protocol, one regarding negative temperatures and one about incorrect parsing of the bits. You could try what happens before and after commit d364d3e
 
Reply
#7
EPSILON,

That part of code gets the offset values for individual devices, it deals with rounding errors.

send from tapatalk
 
Reply
#8
(03-29-2016, 07:56 PM)pilino1234 Wrote: Yes, I've had similar problems before when compiling pilight and having an apt version installed at the same time. What I usually end up doing is to completely uninstall the apt version, and then compile pilight like this:
Code:
cmake .
make -j5
without sudo make install. Then you can't run the wrong version by accident, the executables will be placed in the directory where you are compiling from. Then you can run them with (for examplesSmile
Code:
sudo ./pilight-daemon
@pilino1234,

As I'm implementing a new protocol I run into the same problem again with the alecto_wx500 protocol not seeing my Weather Station, VENTUS W044 sensor anymore.. I apt-get remove'd pilight and now compiling it myself with no avail. After some digging I found out that the type-1 sensor (which apparently is what this sensor is) exits with a parity error.

After changing lines 110~112 the sensor readings shows up again in pilight.
Code:
          .
          .
    logprintf(LOG_ERR, "alecto_wx500: parsecode - (n2 & 0x6) is %d", (n2 & 0x6));
    if((n2 & 0x6) != 0x6) {
        type = 0x1;
        checksum = (0xf-n0-n1-n2-n3-n4-n5-n6-n7) & 0xf;
        if(n8 != checksum) {
            logprintf(LOG_ERR, "alecto_wx500: parsecode - checksum error on type %d", type);
            //type=0x5;
            //return;
        }
    //Wind average * 0.2
          .
          .
    logprintf(LOG_ERR, "alecto_wx500: parsecode - switch(%d)", type);
    alecto_wx500->message = json_mkobject();
    switch(type) {
        case 1:
          .
          .
In my pilight.log I now have the following entries:
Code:
[Jul 04 14:58:28:715156] pilight-daemon: INFO: rule #37 Pulse was parsed in 0.001533 seconds
[Jul 04 14:58:55:107246] pilight-daemon: ERROR: alecto_wx500: parsecode - (n2 & 0x6) is 4
[Jul 04 14:58:55:107382] pilight-daemon: ERROR: alecto_wx500: parsecode - checksum error on type 1
[Jul 04 14:58:55:107466] pilight-daemon: ERROR: alecto_wx500: parsecode - switch(1)
[Jul 04 14:59:27:744297] pilight-daemon: ERROR: alecto_wx500: parsecode - (n2 & 0x6) is 4
[Jul 04 14:59:27:744432] pilight-daemon: ERROR: alecto_wx500: parsecode - checksum error on type 1
[Jul 04 14:59:27:744519] pilight-daemon: ERROR: alecto_wx500: parsecode - switch(1)

while the received data is correct:

Code:
--
"message": {
        "id": 28,
        "temperature": 27.9,
        "humidity": 41.0,
        "battery": 1
},
"origin": "receiver",
"protocol": "alecto_wx500",
"uuid": "0000-7c-dd-90-8c483f",
"repeats": 1
}
--
"message": {
        "id": 28,
        "temperature": 27.9,
        "humidity": 41.0,
        "battery": 1
},
"origin": "receiver",
"protocol": "alecto_wx500",
"uuid": "0000-b8-27-eb-048c50",
"repeats": 1
}
--

Is it a "big deal" to remove the parity check for the type-1 protocol?
 
Reply
#9
Yes, it may be that different devices have different characteristics, only if proven that the original device has the same problem it should be changed, otherwise a new protocol has to be created, or additional logic that will differentiate between devices.

@curlymo,
I do propose to add a new optional json object to the protocol "paritydisable" that will disable the paritycheck, instead of implementing a 2nd protocol.
send from tapatalk
 
Reply
#10
(07-05-2016, 06:55 AM)wo_rasp Wrote: I do propose to add a new optional json object to the protocol "paritydisable" that will disable the paritycheck, instead of implementing a 2nd protocol.
I second that!
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
Tongue pilight 8.1.5-1-gc0a175e0 Chrashes fleisch 4 154 08-17-2019, 01:04 PM
Last Post: curlymo
  pilight for Raspbian Buster (raspberry pi 4) ? starob 29 1,604 07-15-2019, 08:45 PM
Last Post: curlymo
  pilight-receive Filteroption not working Alex 2 363 07-14-2019, 08:35 AM
Last Post: Alex
  pilight usb nano format conversion ettman8 2 254 07-14-2019, 08:32 AM
Last Post: curlymo
  pilight 8.1.4 crashes after some hours Ulrich.Arnold 47 2,050 06-29-2019, 08:58 PM
Last Post: curlymo
  Raspberry PI, gpio-ir-tx and pilight not starting lordslash 5 563 06-11-2019, 05:19 PM
Last Post: curlymo
  pilight fails starting on boot Alex 5 490 06-09-2019, 06:02 PM
Last Post: curlymo
  Google Assistant coupled to pilight hansrijn2 4 936 05-29-2019, 06:54 PM
Last Post: curlymo
  pilight-send does not stop (terminate) va13 3 479 05-15-2019, 06:06 PM
Last Post: curlymo
  oom_reaper: reaped process pilight-daemon va13 4 544 05-15-2019, 08:03 AM
Last Post: va13

Forum Jump:


Browsing: 1 Guest(s)