Open disaster123 opened 2 years ago
In debug mode it just logs / shows:
telenot | debug: unknown string: 68
telenot | debug: unknown string: 54
telenot | debug: unknown string: 54
telenot | debug: unknown string: 68
telenot | debug: unknown string: 73
telenot | debug: unknown string: 02
telenot | debug: unknown string: 48
telenot | debug: unknown string: 24
telenot | debug: unknown string: 00
telenot | debug: unknown string: 00
telenot | debug: unknown string: 00
telenot | debug: unknown string: 01
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: fb
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: 7f
telenot | debug: unknown string: ff
telenot | debug: unknown string: bd
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ef
telenot | debug: unknown string: bd
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: 7f
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: 06
telenot | debug: unknown string: 56
telenot | debug: unknown string: 11
telenot | debug: unknown string: 11
telenot | debug: unknown string: 11
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: ff
telenot | debug: unknown string: 92
telenot | debug: unknown string: 16
Which Firmware and Complex Model you're using?
Complex 400h - Firmware .- no idea - how to check?
But this looks more like a buffering problem - i've connected the complex 400h directly to the server and i'm using socat to map the local ttyUSB0 to tcp
Yes, actually the Telenot is sending you 1 string value which then contains the data. So, the debug shows that you serial connection is not able to get the whole data but send each byte to the program. Here I'm expecting rather the whole string, which I'm then parsing. You would need then so check your socat instance to deliver the whole string - just guessing.
OK now i get:
telenot | info: Connected to TCP converter
telenot | info: MQTT Connected
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: unknown string: 685454687302482400000001fffffffffffffffffffffffffffffffffffffffffffffbffffffffffffffffffffffffffffffffffffffffffffffff7fffbdffffffefbdffff7fffffffffffffffffffff0656111111ffffff9216
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: unknown string: 684c4c687302402400050002fefffffffffffe9e9e9e9e9e9e9e5f3edeffffffffffffffffffffffffff5f3efeffffffffffffffffffffffffffffffffffffffffffffffffffffff0656111111ffffffa316
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: unknown string: 685454687302482400000001fffffffffffffffffffffffffffffffffffffffffffffbffffffffffffffffffffffffffffffffffffffffffffffff7fffbdffffffefbdffff7fffffffffffffffffffff0656111111ffffff9216
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: unknown string: 684c4c687302402400050002fefffffffffffe9e9e9e9e9e9e9e5f3edeffffffffffffffffffffffffff5f3efeffffffffffffffffffffffffffffffffffffffffffffffffffffff0656111111ffffffa316
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: unknown string: 685454687302482400000001fffffffffffffffffffffffffffffffffffffffffffffbffffffffffffffffffffffffffffffffffffffffffffffff7fffbdffffffefbdffff7fffffffffffffffffffff0656111111ffffff9216
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: unknown string: 684c4c687302402400050002fefffffffffffe9e9e9e9e9e9e9e5f3edeffffffffffffffffffffffffff5f3efeffffffffffffffffffffffffffffffffffffffffffffffffffffff0656111111ffffffa316
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: unknown string: 685454687302482400000001fffffffffffffffffffffffffffffffffffffffffffffbffffffffffffffffffffffffffffffffffffffffffffffff7fffbdffffffefbdffff7fffffffffffffffffffff0656111111ffffff9216
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: unknown string: 684c4c687302402400050002fefffffffffffe9e9e9e9e9e9e9e5f3edeffffffffffffffffffffffffff5f3efeffffffffffffffffffffffffffffffffffffffffffffffffffffff0656111111ffffffa316
Hi... as Michel posted on the main page, the string changes depending on the Firmware.
He wrote: " For 25.56 it's for Meldebreiche /^(.)6846466873023a24000500020(.?)16$/ and for Meldegruppen /^683e3e6873023224(.?)16$/. Lately I updated to Firmware 33.68 where the REGEG string has changed for Meldebreiche /^(.)6860606873025424000500020(.?)16$/ and for Meldegruppen /^689393687302872400000001(.?)16$/."
I'm on firmware 35.72 and my strings were: Meldebereiche 683e3e68730232240005000200 16 Meldegruppen 682e2e687302222400000001 16
==> you have to update the regex in socketHandler.js accordingly to your string...
Thanks - how do I know which one is for which kind? Do they have a fixed length? To know when data starts?
I think you need to do it propably with try and error approach. That's how I startet. I saved the first string and then I opened a window. Now I checked which bit has changed. Then I opened another window and so I was able to figure out which bit position belongs to which. As I have different items for Meldegruppen and Meldebereich I could also figure out which string belongs to which item. After I now figured out all my items I was able to map also the bit positions to the bit position shown in CompleX software. Hope this helps to figure out your items. (Also it's quite useful to set the DISCOVER Mode to "true". This will give you the bit positions which have been changed)
ok thanks so far. I'm still not sure how to distinguish between Meldegruppen and Meldebereiche...
If i open a single door i get this output:
telenot | debug: Meldegruppen 685454687302482400000001fffffffffffffffffffffffffffffffffffffffffffffbffffffffffffffffffffffffffffffffffffffffffffffff7bffbdffffffefbdffff7fffffffffffffffffffff0656111111ffffff8e16
telenot | debug: MELDEGRUPPEN - Byte:47 Bit:2 Position:378: Hex: 0x17a Old: 1 - New 0
telenot | debug: MELDEGRUPPEN - Byte:76 Bit:2 Position:610: Hex: 0x262 Old: 0 - New 1
telenot | debug: MELDEGRUPPEN - Byte:76 Bit:3 Position:611: Hex: 0x263 Old: 0 - New 1
telenot | debug: MELDEGRUPPEN - Byte:76 Bit:4 Position:612: Hex: 0x264 Old: 1 - New 0
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: Meldebereiche (164) 684c4c687302402400050002fefffffffffffe9e9e9e9e9e9e9e4f3edeffffffffffffffffffffffffff5f3efeffffffffffffffffffffffffffffffffffffffffffffffffffffff0656111111ffffff9316
telenot | debug: MELDEBEREICHE (Fenster KG Hobby) - Byte:16 Bit:4 Position:132: Hex: 0x84 Old: 1 - New 0 - INVERTED: true
telenot | debug: MELDEBEREICHE - Byte:70 Bit:4 Position:564: Hex: 0x234 Old: 0 - New 1
telenot | debug: MELDEBEREICHE - Byte:70 Bit:5 Position:565: Hex: 0x235 Old: 1 - New 0
telenot | debug: Send CONF_ACK for SEND_NORM
How to interpret this? I would expect a single bit change...
If you open a door you get more than 1 thing changed. Also the "Alarm Bereit Intern" and "Alarm Bereit Extern" will change their bit. So, just open another window and you'll see the two bits are also changing at the next door/window. And then there should one additional bit that has changed to the previous window. Can you share the output when you opened another "thing".
Just guessing that MELDEGRUPPEN Byte 76 / Bit 2,3,4 will always be there. This would mean your door is Byte 47 / Bit 2 at Meldegruppen. Also in Meldebereiche Byte 70 seams to be for Alarm Intern/Extern and Byte 16 is your door.
sure here we go:
telenot | debug: Meldegruppen 685454687302482400000001fffffffffffffffffffffffffffffffffffffffffffffbfffffffffffffffeffffffffffffffffffffffffffffffff7fffbdffffffefbdffff7fffffffffffffffffffff0656111111ffffff9116
telenot | debug: MELDEGRUPPEN - Byte:30 Bit:0 Position:240: Hex: 0xf0 Old: 1 - New 0
telenot | debug: MELDEGRUPPEN - Byte:76 Bit:0 Position:608: Hex: 0x260 Old: 0 - New 1
telenot | debug: MELDEGRUPPEN - Byte:76 Bit:1 Position:609: Hex: 0x261 Old: 1 - New 0
telenot | debug: Send CONF_ACK for SEND_NORM
telenot | debug: Meldebereiche (164) 684c4c687302402400050002fefffffffffffe9e9e9e9e9e9e9e5d3edeffffffffffffffffffffffffff5f3efeffffffffffffffffffffffffffffffffffffffffffffffffffffff0656111111ffffffa116
telenot | debug: MELDEBEREICHE (Fenster KG Fitness) - Byte:16 Bit:1 Position:129: Hex: 0x81 Old: 1 - New 0 - INVERTED: true
telenot | debug: MELDEBEREICHE - Byte:70 Bit:1 Position:561: Hex: 0x231 Old: 1 - New 0
telenot | debug: Send CONF_ACK for SEND_NORM
Thanks a lot!
It's important to only open one at a time when you do the discover. You new output strengthen my guess that Byte 76 and Byte 70 for Status Values. So, next you can update the values in the config file with name and hex code. But you're making progress.
Yes i opened just one at a time. OK - I think i got it. It's really try and error ;-( Is there no way to map those stuff automatically? Or is this just a missing piece of documentation? I'll have a look at the code from https://github.com/smarthomej/addons/tree/3.2.x/bundles/org.smarthomej.binding.telenot it seems it detects already some stuff automatically...
For me I could at least map the Hex Positions to the items listed in ComplexX software. So, it's an initial try&error and then I can get the rest from the complexX documentation. Having a way to determine at least the Alarm status values would be great as these probably exist in every installation. We would need to understand better the string that is received... Maybe the guys from OpenHAB are willing to explain the logic in the string and how to parse it more efficient.
Hello @disaster123 I am the creator of the Telenot binding. If you'd like to test the binding, I'd love to hear from you that it works for you. My firmware is very old and I don't want to update it.
@michelde I hope it's okay for you that I comment here
Best regards Ronny
Sure, I'm just about to understand your coding ... (https://github.com/smarthomej/addons/blob/48e2cfb0161cde948e706d0bf1135a0e57c9d1c0/bundles/org.smarthomej.binding.telenot/src/main/java/org/smarthomej/binding/telenot/internal/protocol/TelenotMsgType.java#L66). I think I would need to enhance my coding as well for the messageTypes....
@rogrun
thanks but i'm using iobroker - so something like this docker container parsing the stuff to mqtt is what i need. I think your binding cannot run on its own... so i can't test.
Okay I understand. No problem.
@michelde i already implemented the whole msgtype detection from https://github.com/smarthomej/addons/blob/3.2.x/bundles/org.smarthomej.binding.telenot/src/main/java/org/smarthomej/binding/telenot/internal/protocol/TelenotMsgType.java to your node software.
Will create another pull request soon.
Hello @rogrun again, i tried to test your adapter with openhab but it seems i'm too stupid to get it running without deeper openhub knowlege. I've created a single thing telenot and can connect fine - but how to proceed? I see no channels...
@disaster123 You have to enable discovery in the settings of the Telenot Serial IP Bridge thing. After about 3-5 min there should be discovered things into the inbox. Add these things and go into the things area. Click the thing an look in the channels. After this you have to link these channels to items.
I hope I could help.
@rogrun mhm i only got one inbox item "Telenot Security Area 1" not more not less...
@disaster123 : I also installed OpenHAB just for interest. In the Security Area you should see some channels. Here I can see the status things like arm internally, ... I created items for some of them and put them on a sitemap. Then I was able to see the status values. But the door and window states I also don't get automatically. Maybe it's because of my missing knowledge and not proper reading the documentation.
Maybe the new firmware is not supported. Please look in the OpenHAB logfiles. There should be further information. Like UNKNOWN or INVALID Massage
I forgot something. It's a longe time ago 😀 Please add the input and output thing. After this enable the discovery in the bridge and the available channels are created in the input and output thing. (After a view minutes) Every used contacts are requested over GMS. For each request it takes 6 Seconds. Sorry for my mistake
@rogrun mhm i can't find any input or output thing:
I mean these things.
Have you tried this?
[edit]: you can find the docs here: https://docs.smarthomej.org/3.2.9/org.smarthomej.binding.telenot.html I'll be update the docs with the hint, that you first add the:
and after this, you need to enable discovery in the bridge thing.
(Ich sollte lieber auf Deutsch schreiben und nicht immer schnell mal nebenbei Antworten. Entschuldige bitte die unklaren Antworten)
@rogrun : Cool. For me it worked now and I can see all items! Good job.
OK thanks a lot! Works nicely. I'll try to simply export those via MQTT to my iobroker :-)
@michelde Thanks 😊 On wich firmware is your telenot? Did you receive my mail?
@disaster123 thanks also to you for testing
@rogrun : I got your mail. Next I would need to get this also adopted to my Telenot adapter. This your information from the mail I got at least all information I need - just find the time to implement it. My Telenot is on Firmware 36.78 - not the latest but not the oldest ;-).
@michelde I am pleased to hear that it also works with other firmwares. I'm looking forward to your implementation, maybe I can use your ideas to improve my binding. So promise a win win situation with our cooperation.
@rogrun do you know any easy way to export all channels and things automatically via mqtt without the need to create an item for each channel?
@disaster123 There is no other way to provide the data via mqtt. You must create an item for each channel. After that you can link each mqtt channel through the same item.
@rogrun what is the right way to report bugs for your openhab adapter?
@disaster123 you can open an issue at the SmartHomeJ project or on my fork rogrun/addons or if you want to communicate in German, you can find my mail in the PR here [https://github.com/smarthomej/addons/pull/296](https://github.com/smarthomej/addons/pull/296
I prefer German, it's easier for me
Hello,
i've successfully configured the GMS and i also see some "stuff" through minicom on the serial port. But for example if i open a door or close a window nothing happens on the GMS.
Greets, Stefan