Off-cloud research

[jilleb]

@guino, I hope you don't mind me creating a seperate issue, but I think it helps to keep the other topics on-topic and easier to read.

So let's discuss here what's what when it comes to off-cloud/offline usage of the doorbell. Currently it uses the Tuya cloud, which means the following, according to @m11tch research

when internet connectivity is blocked:

• you can not view recordings from tuya app, so seems to be streaming directly from SD upon request.
• RTSP is not available. (connection refused) (will check logs later)
• snap.cgi and mjpeg.cgi work fine
• button press does make the "ding dong" sound, but no mqtt message is sent (will check logs later)
• Camera still switches to night mode if dark

[jandy123]

@m11tch Hmm, just connection glitches then ?

Anyways, let's try to see if we could cook up an SD version :)

Edit: Could you please try tuya app streaming in HD, under perfect conditions ? Even placing the bell close to router, etc.

[m11tch]

@jandy123 the accesspoint is like 50cm away from the bell atm.. :D threw the stream in iSpy now, lets see if it also freezes there.. I still suspect it might be a VLC issue. will report back soon..

also linked to your writeup in the top post as it will soon be hard to find with all our discussion in this thread :D

[jandy123]

@guino If you have the time, it would be much appreciated if you could do a brief write-up of your initial buffer-overflow "rooting" :).

[jandy123]

@m11tch Pls. try streaming in tuya app and in perfect conditions too ;).

[jandy123]

also linked to your writeup in the top post as it will soon be hard to find with all our discussion in this thread :D

Yep this one is getting too long too...

I still have a question for you guys regarding the HW connection to the chime, but that will come later... maybe we could start another thread at some stage...

[jandy123]

Thanks to @guino here is the (ultra)SD version. Let's test and see what happens. CPU occupancy still very high, though (97%), so not sure it's going to help much.

===

I use top to look at occupancy, but is this accurate ? I mean process occupancy is 97% but the "overall" occupancy is just ~15%. How should one interpret this ?

ppsapp-rtsp6.zip

[m11tch]

Thanks to @guino here is the (ultra)SD version. Let's test and see what happens. CPU occupancy still very high, though (97%), so not sure it's going to help much.

===

I use top to look at occupancy, but is this accurate ? I mean process occupancy is 97% but the "overall" occupancy is just ~15%. How should one interpret this ?

ppsapp-rtsp6.zip

Hoe much cores does the device have? If there's more then one 100% cpu usage would be 1 core fully utilized

btw.. my CPU usage doesnt even seem to be high atm :confused:

[jandy123]

@m11tch Ok, wired. I just don't get it This is what I have

[m11tch]

Yeah... I normally see the same (when using mplayer or VLC) I will get back to you on this.. btw look at the CPU line:

it says: 14% CPU usage is used in user space and 85% is used in system/kernel space.

for reference:

The difference is whether the time is spent in user space or kernel space. User CPU time is time spent on the processor running your program's code (or code in libraries); system CPU time is the time spent running code in the operating system kernel on behalf of your program.

[jilleb]

Great work guys! I was a bit busy with work today, but will do a "slightly long term" test tonight and tomorrow, connecting the SD RTSP to Surveillance Station while blocking Tuya access.

And... I've played some more with other things inside the software like changing ringtones. But that's maybe for a different topic 😆

[guino]

@guino If you have the time, it would be much appreciated if you could do a brief write-up of your initial buffer-overflow "rooting" :).

@jandy that one was a doosie I am sure I am not going to remember everything... Keep in mind I already had access to my device (using the programmer hack), so from there:

I knew that if I wanted to anything without a programmer I had to find a way to execute something in the SD card. I also had already seen a boot script S90Ppstrong which referenced mounting/using the files from the SD card instead of using the flash memory (when ppsAppParts=0) so I knew that if I could pass that boot parameter I could get it working.

So I had to look at some docs/uboot samples to figure out the custom uboot load address and eventually (after many tries) I got it right. With uboot address defined correctly I was able to get ghidra to show the correct references between code<->data so I looked for the code that asked for password on UART -- found that code, then found where the UART password was store, de-obfuscated it, then had access to the uboot to modify the boot parameters.

From there I found that just setting bootargs normally would not do the trick because their custom uboot prepares a bunch of parameters (including ppsAppParts) automatically so I had to find a way to make ppsAppParts=0 which was basically fill in the kernel command line so that their added ppsAppParts was cut off. When that worked I had a way to hack it without a programmer but still required opening it and connecting to UART (which requires hardware and in some cases soldering).

Next I knew that if I didn't want to use UART I would have to find a way to get it to do anything from the SD card and the only option was that ppsMmcTool.txt which had unknow format, so I went back to ghidra and spent a lot of time figuring out what format was expected of that file and if it could potentially execute any uboot commands.

I found that the 'upgrade' command executed a command which included the filename parameter from ppsMmcTool.txt so I could place a command divider and have mode commands executed there but the file name had a size limit (which means I couldn't set the long bootargs with it). So I made the upgrade filename short (env) and used the fact that it was already loaded into memory to have uboot import and save that new command line parameter, and after a few tries that worked, so having ppsMmcTool.txt, env file and a custom initrun.sh in the SD card (to do what the original one did + what we needed) would work.

There are some older boot loaders that don't support the commands and/or load the file to a different address so the hack doesn't seem to work on these and it's hard for me to adjust it without having a similar device to look at. I saw one that loaded at a different address (81000000 instead of 42000000) and had no command to save the environment so not much of an option there -- possibly have to use the flash commands to modify it but that still requires UART access and it is very specific to hardware/firmware (and I wouldn't try it without a programmer to backup/restore the flash).

[jandy123]

@jilleb

...like changing ringtones. But that's maybe for a different topic laughing

Sounds great... thinking already about my next chime song ;).

[jandy123]

@guino Excellent stuff !!!

Thanks for the details...

[guino]

@jandy123 if for some reason you need specific details like uboot load address, etc just let me know.

[m11tch]

also linked to your writeup in the top post as it will soon be hard to find with all our discussion in this thread :D

Yep this one is getting too long too...

I still have a question for you guys regarding the HW connection to the chime, but that will come later... maybe we could start another thread at some stage...

I came across this post in regards to connecting to traditional hardware chime/bell.. not sure if you want to go down this route https://gathering.tweakers.net/forum/list_message/65126620#65126620

Alternatively you can do it in your home automation / node red based on the mqtt button press 😉

[jandy123]

@m11tch I knew that forum ;) Well, I'd like to go one of these:

• 433MHz RF transcorder + ESP8266 (as RF transcorder and WIFI switch for hassio) + Cheap-(action-grade)-RF-chime
• use my old analog bing-bang; for instance, I see that marmitek Buzz LO has a so-called "doorbell kit" box. Very curious what that actually consists of. See https://www.marmitek.com/nl/smart-me/smart-security/deurbel-met-camera/bell-me-wht-draadloze-deurbel/

Btw. I do not want a wifi/zigbee-only (smart ;) hassio solution.

[jandy123]

Right, so the SD version also got stuck with

[00007f884415f030] main decoder error: Could not convert timestamp 672083512435 for g711
[00007f884415f030] main decoder error: Timestamp conversion failed (delay 1000000, buffering 0, bound 3000000)

although ppsapp still runs... I still dislike the high CPU occupancy.

@m11tch Is CPU occupancy player-dependent ???

[jandy123]

@m11tch Well, you see you forced me to think to just realise that I could use this: https://ewelink.coolkit.cc/?p=886 to implement my 1st bullet. I still have 2 of them lying around...

Edit: Sure with tasmota, custom rf-chip fw, etc...

[m11tch]

@m11tch Well, you see you forced me to think to just realise that I could use this: https://ewelink.coolkit.cc/?p=886 to implement my 1st bullet. I still have 2 of them lying around...

Edit: Sure with tasmota, custom rf-chip fw, etc...

I have rflink connected to my home assistant server for 433mhz stuff so I could use that for cheap 433mhz bells (I have one of them laying around) edit, how does the marmitek work though? Does our bell send out 433mhz signal on button press? (I haven't checked rflink logs yet if it does or not)

[m11tch]

Right, so the SD version also got stuck with

[00007f884415f030] main decoder error: Could not convert timestamp 672083512435 for g711
[00007f884415f030] main decoder error: Timestamp conversion failed (delay 1000000, buffering 0, bound 3000000)

although ppsapp still runs... I still dislike the high CPU occupancy.

@m11tch Is CPU occupancy player-dependent ???

well, the stream in iSpy is still working flawlessly since 17:48, so 3 hours now without issues and low cpu load..

just started it via VLC again, 95% CPU straight away..

@jilleb how is the CPU load when using surveillance station?

okay lets compare:

RTSP Stream via iSpy:

[01-01 08:58:56:768 TUYA Info][rtsp_server.c:508] begin___, client sockfd(47)!

[01-01 08:58:56:768 TUYA Info][rtsp_server.c:513] find a free worker(0) to do...

[01-01 08:58:56:768 TUYA Info][rtsp_server.c:542] end___

[01-01 08:58:56:772 TUYA Info][rtsp_server.c:420] begin___, (0x723df8)

[01-01 08:58:56:779 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (79)
OPTIONS rtsp://192.168.2.89:8554 RTSP/1.0
CSeq: 1
User-Agent: Mozilla/5.0

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD

[01-01 08:58:56:785 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (105)
DESCRIBE rtsp://192.168.2.89:8554 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Mozilla/5.0

[2020-12-10 20:51:1.334] tuya_ipc_echoshow.c get_sdp(462)
[2020-12-10 20:51:1.334] tuya_ipc_echoshow.c get_sdp(462)

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 2
Content-Type: application/sdp
Content-Length: 576

v=0
o=- 3603282 1
s=tuya live stream
i=LIVE555 Streaming Media v2012.04.04
t=0 0
a=tool:LIVE555 Streaming Media v2012.04.04
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:tuya live stream
a=x-qt-text-inf:LIVE555 Streaming Media v2012.04.04
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:96
a=rtpmap:96 H264/90000
a=cliprect:0,0,640,360
a=framesize:96 640-360
a=fmtp:96 packetization-mode=1;profile-level-id=42801E
a=control:video
a=range:npt=now-
m=audio 0 RTP/AVP 97
c=IN IP4 0.0.0.0
a=rtpmap:97 PCMU/8000/1
a=control:audio
a=range:npt=now-

[01-01 08:58:56:799 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (131)
SETUP rtsp://192.168.2.89:8554/video RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
CSeq: 3
User-Agent: Mozilla/5.0

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 3
Session: 1607977724
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

[01-01 08:58:56:802 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (152)
SETUP rtsp://192.168.2.89:8554/audio RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=2-3
CSeq: 4
User-Agent: Mozilla/5.0
Session: 1607977724

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 4
Session: 1607977724
Transport: RTP/AVP/TCP;unicast;interleaved=2-3

[01-01 08:58:56:805 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (116)
PLAY rtsp://192.168.2.89:8554 RTSP/1.0
Range: npt=0.000-
CSeq: 5
User-Agent: Mozilla/5.0
Session: 1607977724

[01-01 08:58:56:805 TUYA Info][rtsp_server.c:259] begin___, rtsp://192.168.2.89:8554 2

[01-01 08:58:56:805 TUYA Info][rtp_server.c:785] begin___

[01-01 08:58:56:805 TUYA Info][rtp_server.c:797] end___

[01-01 08:58:56:805 TUYA Info][rtp_server.c:663] set stream sockfd(47)

[01-01 08:58:56:805 TUYA Info][rtp_server.c:663] set stream sockfd(47)

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 5
Session: 1607977724
Transport: RTP/AVP/TCP;unicast;interleaved=2-3

RTSP stream started by VLC:

[01-01 09:00:42:290 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (118)
OPTIONS rtsp://192.168.2.89:8554 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 2
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD

[01-01 09:00:42:298 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (144)
DESCRIBE rtsp://192.168.2.89:8554 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

[2020-12-10 20:52:46.847] tuya_ipc_echoshow.c get_sdp(462)
[2020-12-10 20:52:46.848] tuya_ipc_echoshow.c get_sdp(462)

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 3
Content-Type: application/sdp
Content-Length: 576

v=0
o=- 3603282 1
s=tuya live stream
i=LIVE555 Streaming Media v2012.04.04
t=0 0
a=tool:LIVE555 Streaming Media v2012.04.04
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:tuya live stream
a=x-qt-text-inf:LIVE555 Streaming Media v2012.04.04
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:96
a=rtpmap:96 H264/90000
a=cliprect:0,0,640,360
a=framesize:96 640-360
a=fmtp:96 packetization-mode=1;profile-level-id=42801E
a=control:video
a=range:npt=now-
m=audio 0 RTP/AVP 97
c=IN IP4 0.0.0.0
a=rtpmap:97 PCMU/8000/1
a=control:audio
a=range:npt=now-

[01-01 09:00:42:305 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (174)
SETUP rtsp://192.168.2.89:8554/video RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=64022-64023

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 4
Session: 1608483214
Transport: RTP/AVP/UDP;unicast;client_port=64022-64023;server_port=65022-65023

[01-01 09:00:42:326 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (195)
SETUP rtsp://192.168.2.89:8554/audio RTSP/1.0
CSeq: 5
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=64024-64025
Session: 1608483214

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 5
Session: 1608483214
Transport: RTP/AVP/UDP;unicast;client_port=64024-64025;server_port=65024-65025

[01-01 09:00:42:337 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (155)
PLAY rtsp://192.168.2.89:8554 RTSP/1.0
CSeq: 6
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Session: 1608483214
Range: npt=0.000-

[01-01 09:00:42:337 TUYA Info][rtsp_server.c:259] begin___, rtsp://192.168.2.89:8554 2

[01-01 09:00:42:337 TUYA Info][rtp_server.c:785] begin___

[01-01 09:00:42:337 TUYA Info][rtp_server.c:797] end___

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 6
Session: 1608483214

first difference:

iSpy seems to be doing rtsp over TCP where as VLC is doing UDP:

########################## RESPONSE
RTSP/1.0 200 OK
Cseq: 3
Session: 1607977724
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

[01-01 09:00:42:305 TUYA Info][rtsp_server.c:455]
########################## RECEIVED (174)
SETUP rtsp://192.168.2.89:8554/video RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.8 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=64022-64023

I believe this is a setting i can do in iSpy.. let me test UDP

CONFIRMED, if I set iSpy to do RTSP over UDP, CPU usage goes to 99% on the doorbell..

[guino]

maybe try: vlc --rtsp-tcp rtsp://ip:8554

EDIT: Tried it, without/with rtsp-tcp: without CPU:97%, with CPU:10%

[m11tch]

maybe try: vlc --rtsp-tcp rtsp://ip:8554

Ppsapp crashed when I did that.. 😂 gotta do some other stuff atm, will try again later. Ah, I see you already tested it.

Guess RTSP over tcp is the way to go then

Edit: @guino can you test if it is also killed after 13 minutes if you're streaming over TCP? Maybe it was killing ppsapp because of high CPU load for longer time?

[jandy123]

@m11tch

how does the marmitek work though?

Via RF 433Mhz.

Does our bell send out 433mhz signal on button press?

Yes, it should. In the Dutch forum you linked to more people confirmed this. Will have to test though to make sure.

@guino,@m11tch: Could you maybe start another "issue" regarding HW linking to chime, etc. ?

===

@m11tch : Good find with TCP vs. UDP. Let's test a bit more and see what happens.

[jandy123]

TCP makes a huge difference: Now usage is <5%, both system and user space; HD too.

[m11tch]

I will check my rflink tomorrow to confirm the bell sends out a 433mhz signal on button press @jandy123

[jilleb]

I will check my rflink tomorrow to confirm the bell sends out a 433mhz signal on button press @jandy123

I can confirm. I linked it to my Homey over 433mhz, as a regular wireless Action doorbell device.

Still looking for that Marmitek connect kit to make it all work with my existing chime, that would be the best.

[jandy123]

@jilleb Did you have to use the LSC app and enable the "Doorbell option" ?

Still looking for that Marmitek connect kit to make it all work with my existing chime, that would be the best.

Yep, question is what is inside. I can imagine that it should react to the 433MHz signal and perform a "shortcircuit" to trigger the analog bell.

[jilleb]

@jilleb Did you have to use the LSC app and enable the "Doorbell option" ?

No. It was on by default. I only used the Tuya smart app to configure the connection and then left it alone. 433 signal is sent by default.

[m11tch]

@jilleb Strange though, I have auto add turned on and it hasn't shown up, maybe the signal is too weak as my office is quite far away from the rflink..

I know kaku devices pair with whatever sends a command in the first minute after plugging it in, does your current chime have similar functionality so that you can pair it to the lsc doorbell perhaps?

I also have a cheap chime/button combo from action that I picked up a year ago or maybe longer.. So I can try that too.. but I have to find it first cause I wasn't using that actively.

[jandy123]

@m11tch Streaming for ~ 30 minutes, HD mode using TCP. Rock solid :).

[jilleb]

@jilleb Strange though, I have auto add turned on and it hasn't shown up, maybe the signal is too weak as my office is quite far away from the rflink..

I know kaku devices pair with whatever sends a command in the first minute after plugging it in, does your current chime have similar functionality so that you can pair it to the lsc doorbell perhaps?

I also have a cheap chime/button combo from action that I picked up a year ago or maybe longer.. So I can try that too.. but I have to find it first cause I wasn't using that actively.

Current chime is hard-wired. I only receive the 433mhz signal on my Homey device currently, haven't paired it yet with a chime, although there's a cheap Action chime in my attack somewhere from a few years ago that I still need to find😆

On my Homey, I enabled the app "Action" which allows for Action 433mHz devices to connect. After that, it was found as soon as I pressed the button on the doorbell.

[jandy123]

@m11tch:

I also have a cheap chime/button combo from action that I picked up a year ago or maybe longer.. So I can try that too..

I don't think that will work, unless it can learn the RF command. Interesting that kaku is able to do so.

[m11tch]

@m11tch:

I also have a cheap chime/button combo from action that I picked up a year ago or maybe longer.. So I can try that too..

I don't think that will work, unless it can learn the RF command. Interesting that kaku is able to do so.

Actually the ones that I know that do this are 433mhz sockets that I bought at action 3 years ago, flamenco brand or something? Anyhow, they are recognized as 'newkaku'

these: https://www.flamingo.eu/en-gb/flamingo-10-046-05-switchset-3-plugs-1-remote-10.046.05 but then the dutch version ofcourse :p

[jilleb]

Mine is "Select plus 200689103". I'll try tomorrow if it works, I don't want to wake up my son/girlfriend 😆

[jandy123]

Well, that's why I intend to use a sonoff RF bridge. Idea is that I can receive the doorbell signal, modify/create a new RF packet and send it to a cheap generic RF chime.

[jandy123]

@jilleb, @m11tch: Well, please let me know if your existing chime works.

[m11tch]

Mine is "Select plus 200689103". I'll try tomorrow if it works, I don't want to wake up my son/girlfriend 😆

the cheap one I have (but cant find atm is also SelectPlus) I'll check tomorrow if It has some learning mode.. otherwise I can just send the command via my RFLink to trigger the cheap chime..

@jilleb I suspect you can do the same with your homey?

but yeah, I dont want to wake up people atm by pressing buttons and setting of chimes left and right :joy:

[jilleb]

@jilleb I suspect you can do the same with your homey? Yes indeed.

Well, that's why I intend to use a sonoff RF bridge. Idea is that I can receive the doorbell signal, modify/create a new RF packet and send it to a cheap generic RF chime.

:-) Good idea. I'll be on the lookout for this Marmitek kit to connect to the existing old-school chime as well. Currently I haven't found one that's sold seperately...

[m11tch]

So I found my chime again, it's this one: https://debadeend.nl/wp-content/uploads/2020/01/9200000077298171.jpg Unfortunately it does not seem to have a learning mode, so it is only set off by the original push button :(

it's not really a problem for me as I can just set of the chime via my home automation, so I don't think I'll be picking up new chimes for this :)

[jandy123]

@m11tch I will try today to get this one https://www.action.com/nl-nl/p/draadloze-deurbel/ It's dirt cheap. Planning to get it working via the RF bridge.

How loud are these things anyway ? My existing analog one can be probably heard by all my neighbours...

[m11tch]

@jandy123 this one seems to have a learning mode: https://klikaanklikuit.nl/product/draadloze-deurbel/ Although, I'm not sure if a kaku device responds to a SelectPlus signal... I think there is a difference between the two signals..

I'll try if the sockets I mentioned earlier respond to selectPlus signal.... first tests show that a 'newkaku' device does not respond to a 'SelectPlus' signal

some more reference material: there is definitely a difference in the RF protocol between kaku and selectplus: http://www.rflink.nl/blog2/protref

idk about the one they are currently selling at action, but the one I have isn't super loud, but since they are wireless you could place them anywhere you want ofcourse to get the best result :)

[m11tch]

So for some reason my RFLink does not detect any 433mhz signal when i press the button on the doorbell...Could it be disabled on mine? :confused: will investigate further later..

[jandy123]

@m11tch: I doubt it's not enabled. Just tested and my rf bridge detects it. I only ever touched the tuya app not the LSC.

[m11tch]

@jandy123 did you use the tuya app to add the device to your wifi or the LSC app? I used the LSC app.. this might cause a difference in config? :S

what does your dev_settings.json look like?

mine has: "external_charm": 0

edit: changed external_charm to 1 and restarted ppsapp/the device, no change.. still not detecting a 433mhz signal.

hmmm, now I did spot something, but out of 4 button presses I only detected 2 433mhz commands, strangely they also have different ID's.. hopefully not some neighbour operating a 433mhz device at the same time as I'm pressing the buttons :joy:

2020-12-11 13:21:12 DEBUG (MainThread) [rflink.protocol] received data: 20;53;E
2020-12-11 13:21:12 DEBUG (MainThread) [rflink.protocol] received data: V1527;ID=0c0d8c;SWITCH=04
2020-12-11 13:21:12 DEBUG (MainThread) [rflink.protocol] received data: ;CMD=ON;
2020-12-11 13:21:12 DEBUG (MainThread) [rflink.protocol] got packet: 20;53;EV1527;ID=0c0d8c;SWITCH=04;CMD=ON;
2020-12-11 13:21:12 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'ev1527', 'id': '0c0d8c', 'switch': '04', 'command': 'on'}
2020-12-11 13:21:12 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'ev1527_0c0d8c_04', 'command': 'on'}

2020-12-11 13:26:32 DEBUG (MainThread) [rflink.protocol] received data: 20
2020-12-11 13:26:32 DEBUG (MainThread) [rflink.protocol] received data: ;54;EV1527;ID=081b18;SWI
2020-12-11 13:26:32 DEBUG (MainThread) [rflink.protocol] received data: TCH=09;CMD=ON;
2020-12-11 13:26:32 DEBUG (MainThread) [rflink.protocol] got packet: 20;54;EV1527;ID=081b18;SWITCH=09;CMD=ON;
2020-12-11 13:26:32 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'ev1527', 'id': '081b18', 'switch': '09', 'command': 'on'}
2020-12-11 13:26:32 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'ev1527_081b18_09', 'command': 'on'}

I'm wondering, is ppsapp responsible for sending the 433mhz command? @jilleb or @jandy123 can you test if you still see the signal if you kill ppsapp?

[jandy123]

@m11tch I also have "external_charm": 0. However, I'm sure the doorbell generates the following message (sonoff rf bridge):

`RfReceived":{"Sync":12820,"Low":430,"High":1260,"Data":"303630","RfKey":"None"}

Rf bridge is in "standard sniffing mode" for PT2260, PT2262, PT2264, EV1527, etc devices. The "Data" above is also consistent across multiple tries. .

[jilleb]

@jilleb or @jandy123 can you test if you still see the signal if you kill ppsapp?

No signal. No chime from the doorbell itself either.

[m11tch]

@jilleb or @jandy123 can you test if you still see the signal if you kill ppsapp?

No signal. No chime from the doorbell itself either.

hmm... I'll hook up the RFLink to my computer after work to see if I can see what's going on..

Edit:

Okay, so my RFLink detects the signal, it just doesnt recognize it, so that is something that needs to be fixed in RFLink firmware, i'm not sure if I care enough about that :D since I don't have any use of propperly detecting the signal in my home automation based on the 433mhz signal... (the mqtt message from logparser is enough for that purpose.. and probably more reliable..because 433mhz is kinda shit :D )

Perhaps we should start a new issue about compatible 433mhz chimes :)

@jandy123 any luck with the other action chime you mentioned?

[jandy123]

@m11tch Perhaps we should start a new issue about compatible 433mhz chimes :) Yep !

any luck with the other action chime you mentioned?

Still looking at it. It's non-standard as in PT2260, PT2262, PT2264, EV1527, which the doorbell is ;). I can, however, send the "raw" signal and trigger the chime, though, using rf bridge ;). At 5.x euro seems like a good investment.... and is loud !

[jilleb]

6

[jandy123]

@jilleb, @guino Could you guys copy some of the discussion in this thread in the one above ?