undefined response

[lucacalcaterra]

What could it be ? Tnx !

[pergolafabio]

Maybe you have the old IP board that only allows 1 session? Or do you have a the port open?

I have older board too , by disabling cloud, you normally can access it

[lucacalcaterra]

Yes i have the one channel module, even disconnecting cloud not works. The error is in attachement

[pergolafabio]

I have never tried it

[gawindx]

I already had the case of capricious central for which it was necessary to restart the module ip when making certain modifications on the network configuration.

The method depends on the Panel model. For agility, we can do it via the config by deactivating then reactivating the IP module (from the keyboard or the Configuration Software). For lightsys and Prosys, all you have to do is delete the module from the configuration, then a search for accessories on the bus allows the module to be detected again and recognized.

After that, there is the universal method which is to cut the power supply to the central unit (mains and batteries) to restart it. For this last method, pay attention to the outputs which could change state when restarting (siren blocking or other).

[TJForc]

It seems that @gawindx has a bit of short memory, we fixed this problem a few weeks ago but I had not yet committed all the changes made recently. I updated the git and the npm package will follow shortly.

@lucacalcaterra, you can rebase your fork, the error message you encounter should display correctly. Unfortunately I think you shouldn't connect anymore, the error was only showing the error message.

To help you solve the connection problem I would need more info:

• the type of panel,
• have you tried the @gawindx method (his suggestion is not silly in itself)
• the error message you encounter (following code update).

I suspect a timeout problem because the single socket IP modules are 10Mb and not 100Mb and I think they are much slower. If this is the case, I already have my little idea to get around this problem.

And as I haven't had much feedback for the moment (or even almost none), you are the first with which we will be able to debug the old IP module.

[vanackej]

Hi @TJForc I am trying to use the library to establish a direct local connection to my Lightsys alarm unit and I get the exact same behavior as @lucacalcaterra I'm not sure what exact Ethernet module version I have, is there any way to retrieve module version without physically opening the Lightsys unit ?

[pergolafabio]

normally if you are connected to cloud, the port should be closed if port closed => old module :-) i also believe the old modules are connected to max 10/100

[TJForc]

@vanackej As far as I know, the old IP modules are 10Mb (this is the case with the Agility and the old modules could also equip the LightSys). If you know how fast the network port connecting your control panel is, it can be a good starting point to identify the module.

The major difference between the old and the new module is that the new module is multi-socket (several simultaneous connections) while the old module is single-socket (1 single connection at a time).

From experience, it is sometimes necessary to reinitialize the IP module following network configuration changes. For the LightSys, this implies:

• enter programming via the keypad,
• remove the IP module from the BUS devices,
• for safety, to exit the programming to validate the change,
• enter programming again
• reconnect the bus to find the module
• go out again.

This can be done directly via the Configuration Software provided that you are connected to the control panel via the RS-232 cable (if you are connected by IP or via the Cloud, it will not necessarily go well since the IP module is used).

Incidentally, the old IP module is identified as an "IPC" module in the Bus peripherals via the keyboard, while the new module is identified as "IPC2". If that can prevent you from opening your unit.

I remind you that the operation with the old IP module remains theoretical in the sense that I have not personally tested it and that I have not yet had positive feedback on this subject.

Another point, I am working on the development of a "proxy" mode which should allow to be inserted between the central and the RiscoCloud and should therefore provide an alternative to this problem. But this mode will require either to modify the programming of the unit to connect to this plugin rather than to RiscoCloud, or to use any other method allowing to make believe to the unit that the IP address of the plugin corresponds to the url "www.riscocloud.com" (having your own DNS server or a router between the central and the network could be suitable) . Making direct connection via RS-232 (or via USB for the Prosys) is also a possible alternative.

[pergolafabio]

That proxy is indeed interesting, otherwise I will update my IPC :+) , i have the old one also

[vanackej]

I really like the proxy idea too ! Maybe simpler to implement and setup. Also probably the exact same API for all units types, no specific code as you have currently in the current implementation.

Have you been able to reverse engineer the protocol between the unit and Risco cloud ?

I'm a bit surprised the unit does not perform any certificate validation/payload signature, it would be a major security issue for such an alarm device...

[pergolafabio]

dont think so, my guess if he starts working on the proxy to connect to panel from cloud, you also need an installer account to access it normal users that dont have the installer account wont be able to use it... could be wrong though

if i connec to my panel with the CS software from cloud, i also need to enther the installer account were the panel was registered on..

[gawindx]

I think the proxy will be between the panel and the riscocloud, so no need for an installer account. the plugin will take care of relaying the information between the two entities (the riscocloud and the panel) but this will allow you to be able to insert commands directly to the central, a bit like a man-in-the middle attack.

As for the reverse of the RiscoCloud protocol, I think it is neither impossible, nor a good idea. If we go in this direction Risco could react and find a solution rendering TJForc's advances inoperative.

[vanackej]

Anyway, in theory it should not be that easy to setup a man in the middle proxy for riscocloud, as it would be a major security issue. I really hope Risco units are protected against such well known attacks. If not I would immediately disable riscocloud on my unit. So yeah on a second thought the proxy idea is maybe not so good.

[gawindx]

Why do you think that since the first versions of the code the option "Disable_RiscoCloud" is active by default?

For this to work, the control unit must connect to the proxy, then the proxy is responsible for transmitting the packets to RiscoCloud, the response is then routed to the control unit. which means that it is not in itself a man in the middle attack, but it is the principle which will be exploited to create a functional proxy. So if you don't have access to the programming of the control panel, or you can't redirect packets to the proxy, it can't work.

[vanackej]

Edit : I just read the other issue discussion (https://github.com/TJForc/risco-lan-bridge/issues/1), a lot of responses here :-)

I'm a little confused by your last message. I don't see anything in the current code that relates to some kind of proxy mode.

From my understanding (can you confirm if I am right @TJForc ?) :

• The current library is just a client for the Risco unit, that communicates with the unit using a TCP Socket. It does not interact with RiscoCloud at all, and has just an option to automatically enable/disable RiscoCloud on the unit side at startup (I'm not really sure why this feature has been introduced, did having cloud connectivity bring some problems when using the library ?)
• @TJForc was just mentionning that he was thinkng about an alternative way to do it (control the unit without RiscoCloud), by implementing a proxy to replace RiscoCloud => The unit would not be aware that the cloud services have been replaced by a local proxy. This is the exact principle of a man in the middle attack, thats why I saied I really hope Risco panels are protected against such attacks. At the end, this proxy won't be implemented so easily (at least using just local DNS resolution override). And the solution involving changes on the panel programming seems technically complex and also not so attracting from a security point of view.

So I'd rather stick to the current local TCP client solution, if I'm able to get it to work. By the way thanks @TJForc for the huge amount of work you've done here, looks very promising. This library, in combination with an MQTT broker (like @lucacalcaterra project https://github.com/lucacalcaterra/risco-mqtt-bridge, but using local TCP socket instead of Riscocloud API) would be the perfect solution home automation systems integration like HA or Jeedom. I think this library will interest a lot of people in these communities because of Risco move to paied cloud access.

Anyway, sorry we're getting far away from the original issue here. The right place for this kind of discussion is maybe a discord channel :-)

[pergolafabio]

Another option is to use the official local API, but you need to be a company to sign the nda to obtain it

[TJForc]

Indeed, this is not the right place to discuss it but I will still answer here before I close this topic.

The proxy mode will in no case be a man-in-the-middle attack but will use the same architecture, namely a double TCP socket: one input which will be connected to the Panel, the second to RiscoCloud. All data identified as communication between the control panel and RiscoCloud will be automatically transmitted from one socket to the other. From there, it is possible to perform intermediate processing, therefore inserting data between the library and the central unit and intercepting the responses to process them without transmitting them to RiscoCloud.

Regarding the public API, I was not satisfied to work only on the software "Configuration Software" to understand the protocol, I also worked with other software which integrates it (or in any case which are capable of communicate in a local network with Risco control panels), I am therefore 99.9% convinced that this protocol is part of the API.

In terms of security, we must stop believing that RiscCloud communication is highly secure. When connecting the control unit to the Cloud, certain information is transmitted in clear, such as:

• the PanelID of the control unit
• Its local IP address (for what purpose?)
• The names of the zones
• More serious, the labels of the users.

For the rest of the communications, they do not seem to me to be encrypted but encoded, by this I mean that it seems to me that the commands are given in binary value but I do not understand them (and do not have the 'intention to go further on this path).

If I can say this, it is because I already have a functional utility that allows you to interpose between the central and the Cloud and both the central and the RiscoCloud does not detect it.

Regarding the options to activate and deactivate the RiscoCloud. They are present for several reasons:

• Allow the user to activate or deactivate the Cloud without having to call on a third party
• Protect themselves from Risco (I remain convinced of the possibility of forcing a firmware update making this library inoperative even if I think that this will involve too many problems for them given their API)
• Allow you to regain control of the system in the case of a single-socket module, subject to successfully connecting to it, but this does not seem possible at all if the Cloud is activated on the control unit
• Serve as proof-of-concept concerning the modification of the programming without the software

Last point: YES, modifying the configuration of the control unit is not within everyone's reach but I think that if we are here it is because we can consider ourselves as informed or at least advanced users, to the others unfortunately it is better to continue using the RiscoCloud and pay Risco.

Now that these points are cleared up, I think we can come back to the original topic, the "undefined" error.

Version 0.9.7 of the code contained a bug that prevented certain types of messages from being displayed (depending on the log level). This problem is corrected in 0.9.8. So, either this problem is solved on your end but the communication is not established and the message "undefined" no longer appears, or the message still appears and it is a consequence of the connection failure linked to the IP module . @lucacalcaterra and @vanackej, I await your feedback on this point.

[pergolafabio]

Last off-topic question, how can we reach you on discord?

[TJForc]

You can't, I'm not on discord. And to be more precise, I am not on social networks or forums or anything.

By email, it suits me perfectly: tjforc@tutanota.com

[vanackej]

Thanks for all the explainations @TJForc 👍

I'm a little concerned with the lack of security of those Risco panels regarding cloud communication protocol 😨 just to be sure : did you just override DNS resolution in your local network to make your unit communicate with your proxy, or did you have to make changes to the panel software ? Or maybe both are possible if I understand your first message well ?

For this library, I'll test and let you know as soon as I'm able to get the installer code from my local retailer (probably tomorrow)

(Sorry for the spam, bad manipulation => comment deleted then sent again)

[gawindx]

By default, the code installer of a lightsys is 1111. You can also try the 2222, it is a secondary installer code which has the same rights to a close detail, it cannot be used to change the installer code. From experience, most installers don't think about changing it, they only change code 1111.

[lucacalcaterra]

Another option is to use the official local API, but you need to be a company to sign the nda to obtain it

@pergolafabio Anyway probably you'll cannot use it on any public project by non disclosure agreement

[Lukino2000]

Hi all,

I have a LIGHTSYS panel with MULTISOCKET card installed but still got the following error.

any tips?

` Local GMT Timezone is : +01:00 Start Connection to Panel TCP Socket is not already created, Create It Pseudo Buffer Created for Panel Id(0001): [2,5,11,23,47,94,189,122,244,232,208,161,66,133,11,22,45,90,181,107,214,173,90,180,104,208,161,67,135,15,31,63,126,253,251,247,239,223,191,127,255,255,254,252,249,242,229,202,149,43,86,172,88,176,96,193,131,6,12,25,50,100,200,144,32,65,130,5,11,23,47,95,190,125,250,245,234,213,170,85,170,84,168,81,162,68,136,17,35,70,140,24,49,98,197,138,21,42,85,171,87,175,94,188,121,243,230,204,152,49,98,197,138,21,43,86,172,88,177,99,198,141,27,54,109,218,180,105,210,165,74,149,42,85,171,86,173,90,181,106,212,168,80,160,64,129,2,4,9,19,39,78,157,58,117,234,213,170,85,170,85,171,87,175,95,190,124,248,240,225,195,135,15,30,60,120,240,224,193,131,6,12,25,51,102,205,154,53,107,215,175,94,189,122,245,235,215,175,95,190,125,251,246,236,216,176,96,192,129,2,4,8,17,34,68,137,19,39,78,156,56,113,227,199,143,30,61,122,245,234,213,171,86,172,89,179,102,205,154,53,107,215,174,92,185,115,231,207,158,61,123,247,239,223,191] TCP Socket must be connected now Process Exit, Disconnecting Disconnecting from Panel. Sending Command : DCN Command CRC Value : A5E8 Command Sent. Sequence : 1 - Data Sent : DCN SendCommand receive this response : undefined file:///D:/Temp/testRiscoLanBridge/index.mjs:13 if ((RPanel.Partitions.ById(1)).Arm) { ^

TypeError: Cannot read property 'ById' of undefined at GetPartitionState (file:///D:/Temp/testRiscoLanBridge/index.mjs:13:28) at file:///D:/Temp/testRiscoLanBridge/index.mjs:20:1 at ModuleJob.run (node:internal/modules/esm/module_job:183:25) at async Loader.import (node:internal/modules/esm/loader:178:24) at async Object.loadESM (node:internal/process/esm_loader:68:5) at async handleMainPromise (node:internal/modules/run_main:63:12) `

[TJForc]

@Lukino2000 So, as it is, it will not be easy to help you for several reasons:

• can you provide your config file or at least the options you provide at initialization?
• I see that the error is located at line 13 of the file 'index.mjs' and considering that this file is not part of my code, can you provide your script to know how you use "risco-lan -bridge "and know if you haven't missed a step?
• last point, can you create an issue dedicated to your problem? because there, you come in a discussion referring to another bug

[TJForc]

@lucacalcaterra @vanackej @pergolafabio For those who are equipped with a single socket IP module and who wish to test the communication with their control panel, the proxy mode is available (from v0.10.2) To use it, you must modify the configuration of the control panel for riscocloud and replace the url 'www.riscocloud.com' by the IP address of the server running risco-lan-bridge. The connection can take several minutes but it works on my end with a LightSYS. To be more precise :

• risco-lan-bridge creates its socket and listens
• a maximum of 2 minutes for connecting the control unit to the socket
• once the control unit is connected, the riscocloud frames begin to be exchanged between the control unit and the riscoCloud
• in the next minute, until the connection is stable between the control unit and the riscocloud, risco-lan-bridge will start to communicate with the control panel.

[pergolafabio]

Aha , interesting!! Thnx for the update

[vanackej]

Hi @TJForc Thanks for the update. I finally went for the direct connection mode, because at the end I don't want to pay for riscocloud at all, and I don't want them to push any firmware update that would break the direct lan communication. After disabling Riscocloud (I have an old generation module), I'm able to communicate with my Lightsys Panel 👍 I just found a little typo in the code, I will submit an issue asap. I'll do more tests in the next few days and let you know if it's all ok.

2 questions/remarks :

• I was not able to use a standard user code => The module only accepts installer code for LAN communication ?
• There is a CLOCK message that is periodically sent. What is the purpose of this message ? Is that a kind of heartbeat in order to keep the connection active ?

[pergolafabio]

Btw, they don't push firmware updates ... You can detach your panel very easy from your installer and create your own installer account to manage your panel ;-)

[vanackej]

I don't want my installer to push any update either 😅 I'll have a look at how to fully revoke my installer access too. I was shocked when they gave me the installer code by phone when I bought the house, with absolutely no proof of my identity.

Le jeu. 28 oct. 2021 à 21:45, pergolafabio @.***> a écrit :

Btw, they don't push firmware updates ... You can detach your panel very easy from your installer and create your own installer account to manage your panel ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TJForc/risco-lan-bridge/issues/2#issuecomment-954147685, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAECPHK6GP3MQDXWELMGUJ3UJGY53ANCNFSM5C4JDH7A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[pergolafabio]

Yeah, i did , because I have attached cameras to my Risco panel, and only with an installer account you can add them to cloud... Don't want to contact always my installer if I just change some IP or password on my camera... And offcourse don't want that they have access to it ..

So called Risco , to detach my panel id from installer , crested my own installer account, added the panel id, and done... So now I manage 1 customer , myself ;-)

[pergolafabio]

@TJForc , can I contact you by mail or Whatsapp?

[gawindx]

he has already given his email address to several users, so I think you can contact him by email. he is not very available so do not worry if he does not respond immediately.

[gawindx]

@pergolafabio And the risco cameras are dahua cameras with firmware modified by Risco, so you can manage them with a dahua app. It may be necessary to set up a port route otherwise with a dahua plugin for homebridge, you must be able to manage them via homekit

[pergolafabio]

No, I don't use the Risco cameras, i uwe my own, i have bought onvif licences.... Those from Risco are to expensive :-) With onvif cameras, you need to confgure the cameras on the installer portal, it's not plug and play .. I don't want that installers can see my cameras

[pergolafabio]

I added cameras in Risco , exposing from my Synology system

[robertboccia]

We any closer to getting local for home assistant?

Robert Boccia

---

From: pergolafabio @.> Sent: Friday, October 29, 2021 6:31:46 AM To: TJForc/risco-lan-bridge @.> Cc: Subscribed @.***> Subject: Re: [TJForc/risco-lan-bridge] undefined response (#2)

I added cameras in Risco , exposing from my Synology system

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FTJForc%2Frisco-lan-bridge%2Fissues%2F2%23issuecomment-954422058&data=04%7C01%7C%7C4896ddac05be4075049e08d99a9504de%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637710787078293969%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0D1VlbdWQXb93A%2FWkM7jHt%2BNSf%2FVe0zTlhFoSxyedFQ%3D&reserved=0, or unsubscribehttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAR4IWBHVT5FL3ZBNNWISDILUJIWUFANCNFSM5C4JDH7A&data=04%7C01%7C%7C4896ddac05be4075049e08d99a9504de%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637710787078293969%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d7r%2FSYS0oFnZjETsL2VhKV%2FYOW43zC2aRHI1y2%2BeM3I%3D&reserved=0.

[TJForc]

@vanackej For user codes, that's the beauty of it. This protocol is dedicated (that's what I deduced from it) for use via supervision software or to allow the integration of Risco products into security software solutions. It is also used for communication between Risco's "Configuration Software", software allowing the configuration of the control units.

The code used by default, namely 5678, is equivalent to the remote user and, from my experience and having discussed this with @gawindx who also has a good experience of Risco products in general, this code is hardly ever changed. because it has no use for an installer who therefore does not see the need to modify it. This remote user therefore has fairly high rights (equivalent to the addition of the installer and master rights) and therefore allows you to perform all the actions you need here.

For the 'Clock' message, yes, it serves as WatchDog to ensure that the connection is still active and to ensure that the control panel does not close the socket due to inactivity (in direct connection, the timeout is 30 seconds memory).

[pergolafabio]

@TJForc , for the new proxy based on cloud , do you need an installer account? I have single socket module, and when I want to connect to panel with CS software, i need to use the installer account

[TJForc]

No need for an installer account, we come between the central and the cloud. On the other hand, it is necessary to modify the configuration of the control unit so that it connects to the Proxy socket which then takes care of connecting to RiscoCloud.

You need to connect with an installer account to your control panel because you use the connection via the RiscoCloud which must then determine if you are authorized to connect to this control panel. Previously (before RiscoCloud V5), it was enough to know the PanelID of the control unit to be able to connect, which was absolutely not secure; this is no longer possible today.

If you were equipped with a Multi-socket IP module, you would be able to connect to your control panel on the local network even if your control panel was already connected to the RiscoCloud and without having to resort to the connection via the RiscoCloud.

[pergolafabio]

Ok, maybe it's time to upgrade my module to a multi socket , would be easier

[pergolafabio]

Anyway, would be great if someone could make an add-on, it's easier for HA users :-)

[TJForc]

If you have access to the configuration of your control panel, proxy mode will suffice. It has been designed to allow the connection without having to abandon the RiscoCloud. On the other hand, it depends on the connection to RiscoCloud. That is, if the connection to RiscoCLoud cannot be established, then the connection to the control panel will be closed.

In your case, I'm not sure that you have to change the module (and it also seems to me that not all versions of lighsys accept it, especially older versions).

[pergolafabio]

Ok , what needs to be changed on the panel ? I have installer account, i can access my panel

[TJForc]

In the connection options to RiscoCloud, you must change the URL and possibly the TCP port. For the URL, it must be defined as 'www.riscocloud.com' and it must be modified to indicate the IP address on which 'risco-lan-bridge' is running. for the TCP port, it is 33000 by default, you must indicate the port on which 'risco-lan-bridge' listens.

Attention, if your HomeBridge is in a container, do not forget to expose the port that you will have configured for 'risco-lan-bridge'.

Last point, the control unit can take up to 2 minutes to connect and I then delayed the connection of risco-lan-bridge by almost 1 minute for the connection to RiscoCloud to be completely established.

[pergolafabio]

Ok, that's clear! I hope someone could make an add-on where we can also define those options for port / IP and also the mqtt stuff, would be great

[pergolafabio]

Guys, i have a lightsys panel, with old IP socket, still running some older firmware version 2.x bougth a new TCP socket module, that requires 5.x

so started first firmware proces on lightsys panel, it starts downloading , but always hangs at 27/531 while updating anyone an idea? anyone tried upgrading?

thnx

EDIT: nm, seems my router was blocking the device... the firmware page where the device is downloading from, is a blacklisted by trendmicro it seems now its downloadling ... fingers crossed all goes well

[pergolafabio]

crap, seems my lightsys (32) is limited, highest version = 2.70 so i'm not able to plugin a multi socket, could be usefull for other people who are in same boat

gonna return the multi socket... not gonna buy a new mainboard just for this :-) Will use the proxy method instead then... :-)

any news about integration with HA?

[vanackej]

Hi,

I've got a working integration at home, using an updated version of this library (see https://github.com/TJForc/risco-lan-bridge/pull/9) and an updated version of the risco mqtt HA integration (see https://github.com/vanackej/risco-mqtt-home-assistant/tree/feature/lan_communication). There are some discussions in progress regarding my PR with @TJForc, so I don't know if it will be available anytime soon for public use. Works perfectly fine at home for the last 3 weeks.

I also have a single socket module, but I don't use proxy mode as I don't want to use RiscoCloud anymore and pay for it. So I don't know if it also work with proxy mode. It should, but no guaranty.

[pergolafabio]

Hey, can you explain me how you did it? step by step? because running this command: npm install risco-mqtt-home-assistant , is not going to install the correct branch? :-)

do i need make a new docker?

maybe we can discuss in another issue thread? or can you create some readme on your repository?

[pergolafabio]

@TJForc , about proxy mode , do i have 2 options here? its not 100% clear to me option1: is to change the panel, instead of www.riscocould.com, i just need to enter there the IP were i run your project? so you are also exposing port 33000 ? what about that password? is it needed? see screenshot option 2 : is make a redirect to forward all traffic to riscocloud.com to the internal ip?

am i correct?