[wo_rasp]

Okay, let us get started, bottom up.

Talking to the bell

pilight-debug shows:
Raw code: 1050 525 1050 525 1050 350 1050 525 1050 1225 350 525 1050 1225 350 1225 350 1225 175 1225 350 525 1050 525 1050 1225 350 525 1050 525 1050 525 1050 525 1050 5950

Sending this RAW-code makes the doorbell ring - sometimes. Why only sometimes? Sometimes it works a few times in a row, then sometimes i have to send the code 10 times before the bell rings. I do not understand the logic behind that behavior either.....

Let us have a look at the raw data you posted (i am sure you edited that raw output but the two last lines reveal the important information:

433gpio: 978 489 984 472 988 477 990 499 970 1206 268 489 979 1200 269 1225 242 1208 261 1217 252 477 989 479 987 1217 258 480 982 491 978 491 974 499 968 5971 -#: 36
433gpio: 982 480 986 488 979 501 967 488 978 1208 262 480 988 1218 257 1217 248 1236 235 1218 250 479 988 489 979 1252 224 479 979 490 981 487 977 488 978 294971 -#: 36

1. The protocol does not have a footer, but it has a header, and we can assume that the value is 5950
2. If you repeat the pulsetrain often eneough a lot of folks here have the opinion "it does not matter".
2.1 It does not matter for pilight during receive, if the pulsetrain is transmitted more than twice, this is the case so receiving is not an issue
2.2 It may matter in some cases, in particular if the receiver is expecting one or more pulses as a wakeup sequence, before starting to listen to incoming RF data.

3. Consequence:
3.1. The raw pulses before you receive the 1st pulsetrain may be important.
3.2. If there is a wake-up pulse pattern present:
3.2.1 You will easily pick it up, and
3.2.2 It may be the reason why you have difficulties that your receiver responds only randomly.

3.3 If there is no wake-up pulse pattern:
3.3.1 The reason for bad reaction may be insufficient strength of the transmitted signal (pretty rare, transmitting of RF is not a common problem).
3.3.2 I do not think that noise is an issue on the transmitter side, as the quality of the received signal is pretty good.
3.3.3 There is a bug in the raw data you use. In your pilight-debug output, i think that the 6th pulse should not be 350 but 525 and the 19th pulse should not be 175 but 350.

4. To find out try other pulsetrains, for example the ones reported by pilight-raw:
4.1

978 489 984 472 988 477 990 499 970 1206 268 489 979 1200 269 1225 242 1208 261 1217 252 477 989 479 987 1217 258 480 982 491 978 491 974 499 968 5971

4.2 or with the header as 1st pulse:

5971 978 489 984 472 988 477 990 499 970 1206 268 489 979 1200 269 1225 242 1208 261 1217 252 477 989 479 987 1217 258 480 982 491 978 491 974 499 968

5. In your C-code:
5.1. The function call createMessage(0,0,0) is not required.
5.2. add printf statements into your code and check if it is called and what the parameters / values are.
5.3. You do need to understand what the indicidual pulses of the raw data represent and how to convert them into binary values.
5.3.1. If you need it just for your own purpose, you can compare if the received string is equal to the raw data you expect to received and set the json objects accordingly ....

[malte]

First: thank you so much for your time and knowledge!!!

2. If you repeat the pulsetrain often enough a lot of folks here have the opinion "it does not matter".

That's ok for me!

3.1. The raw pulses before you receive the 1st pulsetrain may be important.
3.2. If there is a wake-up pulse pattern present:
3.2.1 You will easily pick it up, and
3.2.2 It may be the reason why you have difficulties that your receiver responds only randomly.

Can't find anything like that.

3.3 If there is no wake-up pulse pattern:
3.3.1 The reason for bad reaction may be insufficient strength of the transmitted signal (pretty rare, transmitting of RF is not a common problem).
3.3.2 I do not think that noise is an issue on the transmitter side, as the quality of the received signal is pretty good.
3.3.3 There is a bug in the raw data you use. In your pilight-debug output, i think that the 6th pulse should not be 350 but 525 and the 19th pulse should not be 175 but 350.

Signalstrength is not the problem.
Noise is low, got a filter.
3.3.3 -> I understand and agree. But.... if I correct the raw data, it does not work a single time.... I don't understand that either.

4. To find out try other pulsetrains, for example the ones reported by pilight-raw:
4.1
978 489 984 472 988 477 990 499 970 1206 268 489 979 1200 269 1225 242 1208 261 1217 252 477 989 479 987 1217 258 480 982 491 978 491 974 499 968 5971
4.2 or with the header as 1st pulse:
5971 978 489 984 472 988 477 990 499 970 1206 268 489 979 1200 269 1225 242 1208 261 1217 252 477 989 479 987 1217 258 480 982 491 978 491 974 499 968

Other pulsetrains do work, but also only randomly.
Header as first pulse does not work at all.

5. In your C-code:
5.1. The function call createMessage(0,0,0) is not required.
[/qoute]
Was only a try to make my code SOMETHING happen.

[quote='wo_rasp' pid='20757' dateline='1490773468']
5.2. add printf statements into your code and check if it is called and what the parameters / values are.

I put printf statements in every function of my code, but I don't get any output (see attachment).
Am I right if i guess to see the output of printf() I have to start pilight-recieve and should see it in the console then?
Or where and how will I bee able so the the printf() outputs?

5.3. You do need to understand what the indicidual pulses of the raw data represent and how to convert them into binary values.

Yea, maybe later on ;-)
First I will focus on my initial intention just to DETECT when the doorbellbutton pressed and create a JSON-Message-object for that.
Seems to be hard enough for me.

5.3.1. If you need it just for your own purpose, you can compare if the received string is equal to the raw data you expect to received and set the json objects accordingly ....

YES, that's exactly what ne next and most important steps will have to lead to!

So this time I will hold myself back with the amount of questions ;-)
The most important things for me are now:

1.
Why can't I see any output of my printf statements in my grundig.c (see attachment)?
1.1 what to run/do and where to look? Start pilight-receive, push doorbellbutton and wait to one of my printf-outputs to appear on the console?
1.2 or is there a reason that prevents any function in grundig.c to be called?

The first step is to determine the length of your protocol (e.q. the number of raw pulses including the footer pulses).
The second step is to determine the gap length between two footer value.
Once you have mastered this, the pilight-daemon will call the two callback functions validate and parsecode.

1.2.1
OK, as far as I know the raw-length is 36 including the header. Thet's what pilight-debug says.
1.2.2
"The gap between two footer values..." you say there is no footer but a header...
a) do you mean the header-length of 5950 then?
b) And how did you come to the conclusion that it's a header but no footer, even if it's shown as the last value in the pulsechain?
c) and where to USE this value in grundig.c ?

1.3
As I understood your earlier post, i will have to feed grundig.c with the corner data of the protocol: raw-length and header/footer.


The only things I defined are:
#define PULSE_MULTIPLIER 3
#define MIN_PULSE_LENGTH 173
#define MAX_PULSE_LENGTH 177
#define AVG_PULSE_LENGTH 175
#define RAW_LENGTH 36

1.3.1 >I guess I can throw PULSE_MULTIPLIER away for the moment?
1.3.2 >Is the RAW_LENGTH the rawlength shown in pilight-debug?
1.3.3 >where/how do I define the header-length?

Once you have mastered this, the pilight-daemon will call the two callback functions validate and parsecode.

I am really looking forward to master this at least ;-)

Thanks a bunch again !!!

[wo_rasp]

As said before, pilight can not deal with headers. This is only important if the receiving device requires one or multiple wakeup pulses of a defined length followed by a header pulse. In all other cases the 1st pulsetrain is ignored, the 1st footer pulse is interpreted as the header followed by the next pulsetrain ....

I concluded the header theory from the last received pulsetrain, there is no 5950 pulse but a longer one, however you are right the 36th pulse is always a RF Signal OFF condition thus the last pulse duration can be any value longer than 5950.

What happens when you change the protocol type from RAW to SWITCH ?




Gesendet von iPhone mit Tapatalk

[malte]

Yea, I understood that header/footer/gap thing now! Thank you!

From RAW to SWITCH, still nothing happens. Still helpless how to provoke some output...

As attachments I send some screenshot of the graphical analysis of the signal. I've been too curious ;-)
----------------
UPDATE

Found the outputs of printf() in
\var\log\deamon.log or \var\log\syslog

Of cause.... sorry, lack of basics. But I am workin on it ;-)

But I only get this printf-output which indicates that "void grundigInit(void)" has been called at startup (service pilight start).

I still do not get any reaction by pressing the doorbell-button.
The function validate() isn't called.

I am still not sure how to determine the correct PULSE_MULTIPLIER and if it's important for validate() to be called...
#define PULSE_MULTIPLIER 2
#define MIN_PULSE_LENGTH 173
#define MAX_PULSE_LENGTH 177
#define AVG_PULSE_LENGTH 175
#define RAW_LENGTH 36

Thank you wo_rasp (and TinkerBear_NZ too!) for guiding me so far so patiently.

[wo_rasp]

@curlymo,
Some postings took off to No-No-Land, i have not found any hint in the log, do you have an idea ?

@malte,
1. I do not know why validate() is not called without parsecode() being defined.
2. "Receive only" protocols do not need createcode()
3. To share the results you do need to open your own github account.
The easiest method is to sign in on github.com (using the web interface) with your user name and fork the pilight.git repository from github.com/pilight.
Then clone that repository from your github account (similar to what you did when you cloned it from my wo-rasp repositor, just replace wo-rasp with your username) to your pi.
To learn more on git start reading here, but best method is to get a book on git (in case you did not know yet what to do during the easter break, you have now an assignment :-)
4. You should not add logic to accept protocols after having received them several times, instead you should add logic to your protocol to check for potential problems and sort those problematic pulsetrains out. Typically a pulsetrain is repeated 4 times, but it really depends on the manufacturer. Some do provide CRC bytes, others provice a checksum or parity bit, but all have in common that the pulses are within a +/- 30% range of the nominal expected pulse length and a defined number of pulses, thus you can decide if the pulsetrain got distorted or not, you can even go a step further and reconstruct partially distorted pulsetrains, in particular if they provide a checksum or crc value (some protocols are only transmitted once, others have a varying number of raw pulses, depending on the coding algorithm).
5. Also please have a look at the rewrite branch, i know it is a steep learning path for beginners, in particular as there is virtually no documentation available explaining the differences, but if there is an upcoming V8, that version will be based on the rewrite branch. (There is another hurdle to overcome with compiling V7 and V8 code on the same machine, it is not impossible but it is not bullet proof, the best workaround is setting up development on a VM and crosscompile, or to use two separate PI's for compiling V7 and V8 code).

[curlymo]

There was an issue on the (sponsored) server again. This should be fixed again, but indeed, a few posts can be gone. I do have nightly backups, so if really necessary i can restore some posts.

Because the whole thing is sponsored i don't complain too much

[malte]

Thanks a lot again, WO_RASP.
Maybe you post the github-link again for other people with similar problems?

The clue of the lost posts was, that the other functions like parse_code etc. HAVE to be defined to make it work.

Now it works, and I also was able to create a new own protocol for an old remotecontrol. Thanks to your help.

To integrate the new own protocol to FHEM it needed some modifications in FHEM, you can read about that here:
https://forum.fhem.de/index.php/topic,70132.0.html

[derchrome]

Is there a way to receive data also or is the c- file only for sending?

[malte]

The protocol will also receive the signals from the grundig doorbell qh-831a and will report it in pilight-receive.

---

Here's the linkt to the protocol, thanks Wo_rasp!

https://github.com/wo-rasp/pilight/blob/.../grundig.c

https://github.com/wo-rasp/pilight/blob/.../grundig.h

Overview:
https://github.com/wo-rasp/pilight/tree/...ols/433.92

[derchrome]

Okay, thanks. How can I use the protocol? Do I need to compile pilight? Or just add the protocol to the pilight folder?

Gesendet von meinem XT1562 mit Tapatalk