Modbus response examples for Elektro-Miz Cobra controller with Spider or Buran modules?

Hello.
I'm looking for communication specifications between a Cobra module and external modules to integrate the controller into a smart home system.
The controller acts as a modbus master, works with slave modules with addresses 1-32 (of which 1-6 have their representations in the form of icons on the controller's display), I can make it send the current parameters and I can decrypt most of them.
The controller periodically queries the slaves for the contents of the holding registers and input registers. I presume this is about the module version (holding registers) and the data to change the furnace settings (input registers). I just don't know what the answer should look like.
Maybe there is someone with examples of the answer from, for example, the Spider or Buran module ?

Hello,
I am also looking for specifications or at least any information regarding the communication of the COBRA controller/regulator. So far I have not been able to find anything about it. It seems to be a closely guarded secret. I am therefore keen to join in the work of "decrypting" the protocol that COBRA uses. At the moment I don't have anything to share yet but I think examples of answers I could provide. Does the controller communicate in Modbus/RTU format?

Yes, it is an RTU protocol. The Cobra acts as a master, any modules are slaves, for this the controller can work with six at the same time (theoretically with 32 but only the operation of 6 is shown on the display).
So far I have a reading of the current parameters done. It looks like this:
1. the Cobra sends a type 4 query (reading the input register) every second sequentially from ares 1 to 32, for example:
003 004 000 000 000 001 048 040 (for address 3).
If it gets a response (I send it twice - with a single send there is often no response. Perhaps it is a necessary break in transmission) in which it will be:
003 004 002 054 146 086 253 - the two bytes 054 and 146 are important - it tells the controller that it is to transmit a set with the current parameters. The answer 054 147 gives a different output set (maybe for the Alligator module?), I have not found other combinations.
Responses from addresses 1 and 2, 3 and 4, and 5 and 6 are interpreted as Alligator, Buran and Spider modules and causes the corresponding module icon to be displayed on the controller.
2 Cobra proceeds to transmit status in the form of 20 registers:
003 016 000 000 000 020 040 017 008 022 023 041 000 001 037 002 094 000 199 000 207 000 000 023 001 000 000 000 000 000 039 000 070 000 070 000 089 000 065 000 100 000 003 000 000 000 000 164 166
3 It also queries 10 registers and 10 input registers in transmissions from time to time:
003 003 000 000 000 010 196 078
003 004 000 001 000 010 032 047
Then it probably needs the appropriate data set with which to change the settings.
In addition, the lack of an intelligible response causes the module icon on the controller to flash after a while. I have not noticed any other symptoms.
Added after 15 [minutes]: .
I have also read most of the 016 status:
003 device address
016 write command
000 000 address 00 to write to slave module
000 020 write 20 registers
040 write 40 bytes
017 year
008 month
022 day
023 hour
041 minute
000 second
001 037 CH temperature (29.3) For all temperatures, the temperature is calculated as (first byte*256+second byte)/10
002 094 HUW temperature (60.6)
000 199 feeder temperature (19.9)
000 207 return temperature (20,7)
000 000 ??
023 001 ?? The number changes when changing different settings. I haven't worked this out yet.
000 000 current fan power (on the second byte)
000 000 controller operation (on the second byte: 000 = OFF, 008 = ON)
000 039 CH setting (039=OFF, the other number is the setting in degrees)
000 070 HUW set point (039=OFF, other number is set in degrees)
000 070 guess is the temperature the controller is aiming at at the moment
000 089 controller operation mode (89=PID, 105=ADC, 73=OFF)
000 065 feeder interval time
000 100 maximum fan power
000 003 minimum furnace output
000 000 ??
000 000 ??
164 166 checksum


Now you would need to find out how to construct the responses to queries 03 and 04. It is probably not the same data that is transmitted using command 16. It seems to me that one of the responses should contain the software version of the module. Sending random data did not work. I could have sequentially sent all the combinations in turn, but it would have taken too long and by the time I knew the command had taken effect, I wouldn't have known which one worked. It would be nice to have a Modbus eavesdropping record of the controller's communication with the module. I don't have access to any module so have no way of doing this.

If you need code for the Arduino to implement the protocol, I already have the program ready so I can extract the relevant bits from it. I suppose the whole thing with Nextion display support won't be useful.

You have done a very good job! It will certainly make life easier for many, and certainly for me. Thank you very much.

How did you find those "relevant two bytes 054 and 146" for the answer from under address 003?

Surely a record of the monitoring of the communication with the expansion modules will make it easier and quicker to deepen your understanding of COBRA. Unfortunately, from what I understand, the Buran module never came out. I have been trying to buy one for many years. Communication with it would give a lot of valuable information. Currently only the Alligator and Spider GSM are available on the market.

I do not have physical access to my COBRA at the moment. I will send a private message with a suggestion on how I could help. For the code for the Arduino, thank you very much for now. I think I will hook up with a PC via a USB-RS485 converter and use the available scanners, parsers etc.

It was simple. Cobra was asking for a single register, so I looped the response to each query from Cobra, each time increasing the value sent back by 1. There were 65536 possible combinations, it would take less than 24 hours to send them back. after a few hours I saw that Cobra had started to send back data, quite quickly I determined which code was causing the response. Then it went downhill.

I used to look for a Buran too, but overall it's not necessary. Spider would have been useful. Of course, I can always introduce in the program a cyclic sending of responses to Cobra requests similar to the one I did at the beginning. This time Cobra is asking for 20 bytes of data so it will take a few months, but I don't know what the effect of this will be. I don't want it to turn out that during operation the furnace gets strange parameters and goes stupid. For now, I have decided not to do this and just use the data download from the cooker and display it on the room display.

In case you are annoyed by the module icon flashing on the display, just connect as a slave with an address above 6. There will be no icon.

KonJarek wrote:

In case you are annoyed by the flashing of the module icon on the display, simply connect as a slave with an address above 6. There will be no icon.

Do these "relevant two bytes 054 and 146" check for a response from each slave?

That other set of COBRA output received in response to 054 147 also deciphered?

The message for the second set looks like this:

001 slave address
016 message type
000 000 address of first register
000 040 number of registers
080 number of bytes
000
000
001 215 T CO (47,4)
001 105 T TWU (36,1)
000 194 T feeder (19,4)
001 153 T return (40,9)
000 002
000 039 T CO=OFF
000 070 T CWU = 79
000 000
000 001 ??
043 052 ??
056 000 ??
000 000
000 000
000 000
000 000
000 000
000 000
043 052 ??
000 000
043 052 ??
056 000 ??
000 000
000 000
000 000
000 000
000 000
000 000
043 052 ??
000 000
043 052 ??
056 000 ??
000 000
000 000
000 000
000 000
000 000
000 000
047 000 ??
000 000
9F 99 CRC


I have no idea what these parameters mean, but perhaps they are used to control the starter

However, I was wrong. This second set of parameters is not for communication with the valve but with the Spider module.

The modules work in Modbus RTU, with a speed of 9600.
The communication looks like this:

1. Cobra sends a register request from address 0:
005 004 000 000 000 001 048 078
Spider responds with code 054 147:
005 004 002 054 147 031 061

(2) Cobra queries modem version and status (addresses 1-9):
005 004 000 001 000 008 161 136
Spider replies:
005 004 016 000 212 000 000 000 000 000 000 000 000 000 002 000 015 000 000 057 128
where:
005-module address
004 - Modbus message type
016 - number of returned bytes
000 212 - version 2.12
000 000 CH setting change
000 000 Change of HUW setting
000 000 1=start
000 000 1=stop
000 002 - modem status (001 - initialisation, 002-SIM error, 003-PIN error, 004-logging in, 005-logged in, 006-SMS error)
000 015 - GSM signal level
000 000 - ?
057 128 - CRC

The return of this message with a changed CH, DHW or start/stop setting temperature changes the Cobra settings.

Cobra saves the parameters to the module
005 016 000 000 040 080 000 000 002 172 002 158 000 255 001 003 000 002 000 039 000 080 000 000 001 043 052 056 XXX XXX XXX XXX XXX XXX 000 000 000 043
where:
005-address of module
016 - Modbus message type
000 000 - address of first register
040 080 - 40 registers, 80 bytes
000 000 - error codes (description at the bottom)
002 172 - CH temperature
002 158 - HUW temperature
000 255 - feeder temperature
001 003 - return temperature
000 002 - room thermostat status (0 - off, 1 - on, 2 - not working)
000 039 - set CO temperature
000 080 - set temperature of DHW
000 000 - whether controller is turned on (000 001 - on)
000 001 - whether the controller is off (works alternately with the previous register - only one of them is set to "1")
043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX 000 - first phone number stored in ASCII
000 000 000 043 052 000 000 - ??
043 052 056 049 049 049 049 049 049 048 000 - second telephone number recorded in ASCII (here +481111111110)
000 000 043 052 000 000 - ??
043 052 056 057 057 057 057 057 057 057 057 057 000 - third telephone number recorded in ASCII (here +489999999999)
000 000 - ??
068 - oven temperature in degrees (no fractional part)
000 000 000 - ??
112 134 - CRC

Error codes are in the form of flags. In the first byte, 5 lower bits can be set, in the second byte all 8. Setting several bits will send all set alarms in the text.
first byte:
bit 1 (1) - Large feeder current
bit 2 (2) - High DHW pump current
bit 3 (4) - CH pump high current
bit 4 (8) - Igniter high current
bit 5 (16) - Blower high current

second byte
bit 1 (1) - High boiler temperature
bit 2 (2) - Bin fire
bit 3 (4) - STB alarm
bit 4 (8) - Feeder blockade
bit 5 (16) - Fuel shortage
bit 6 (32) - Open hopper
bit 7 (64) - Bottom ash
bit 8 (128) - Temperature sensor fault

Spider confirms data storage:
005 016 000 000 000 040 193 147

4th Cobra queries 40 registers (first address 0):
005 003 000 000 000 040 068 172
Spider responds:
005 003 080 000 000 002 166 002 157 000 244 001 132 000 002 000 039 000 080 000 000 001 043 052 056 XXX XXX XXX
where:
005 - module address
003 - modbus message type
080 - number of returned bytes
000 000 - ??
002 166 - CH temperature
002 157 - HUW temperature
000 244 - feeder temperature
001 132 - return temperature
000 002 - room thermostat status
000 039 - preset CH temperature
000 080 - set HUW temperature
000 000 - whether controller is turned on (000 001 - on)
000 001 - whether the controller is off (alternates with the previous register - only one of them is set to "1")
043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX 000 - first call
000 000 000 043 052 000 000 - ??
043 052 056 049 049 049 049 049 049 049 048 000 - second telephone
000 000 043 052 000 000 - ???
043 052 056 057 057 057 057 057 057 057 057 057 057 000 - third phone
000 - ???
000 067 - CO temperature in full degrees
000 000 000 - ??
242 018 - CRC

If there is no communication for more than one minute, the module sends last error messages and a "no communication with the controller" alarm

This is probably all that can be extracted from this device .

When communicating with Cobra, response times are very important. A delay of 100ms can result in the message being sent being rejected. After sending, you also need to add some time before switching to receive. When communicating with the Arduino, I set a 10ms delay before transmitting and 100ms at the end before switching the module to receive.

Amazing how much you have managed to do in such a short time. Thank you VERY much!

KonJarek wrote:

.
...
3. Cobra writes the parameters to the module
...
002 172 - CH temperature
002 158 - DHW temperature
000 255 - feeder temperature
001 003 - return temperature
...


Spider confirms data recording:
005 016 000 000 000 040 193 147


4th Cobra queries 40 registers (first address 0):
005 003 000 000 000 040 068 172
Spider responds:
...
002 166 - CO temperature
002 157 - DHW temperature
000 244 - feeder temperature
001 132 - return temperature
...

.

There is a difference between the data that Cobra has sent for writing to the Spider module and the data, after Spider has confirmed the write, that it sends in response to Cobra's query. Shouldn't the data returned by the module after the write be identical to the data that was given to the write?

Is this difference only in the example or does it also occur in reality?

Added after 17 [minutes]: .

KonJarek wrote:

After transmitting you also need to add some time before switching to receive. For short messages I set a 10ms delay before transmitting and 100ms at the end before switching the module to receive.

I assume you are writing about switching to receive via a module such as Spider. I don't really understand why switching to receive too early, even immediately, after sending a reply to Cobra, the master, would spoil something in the communication. For this example, I don't understand why you have to wait 100ms at the end, i.e. after sending a message to the master.

You set a 10ms delay before transmitting (i.e. after receiving a message from the master) for short messages. Are you referring to short messages received from the master, or short messages sent to the master?

Do you use a different delay for longer messages?

The sequences presented are not a concise whole. They should be considered separately, as examples.

I wrote about switching to reception not via Spider but via a module connecting the computer to the RS485 bus. In my case it was something like this: http://yourduino.com/sunshop//index.php?l=product_detail&p=323
Most modules used to communicate the computer with RS485 require some delay between mode switching and transmission. In my case, it was 100% necessary to add a delay between transmitting and switching to receive (after sending data to the module's buffer, time was needed to transmit the transmission over RS485 and switching the module to receive interrupts the transmission). I did not find 100% whether it was necessary to add a delay between switching to transmit and sending the transmission, but without this delay the Cobra read the transmission less frequently (it took longer to send the data correctly). Certainly with the delays set in this way, the transmission runs correctly despite the fact that I sometimes have problems with interference due to the long interconnecting cable.

The one with the short messages was a mistake (it was about broadcast messages from the Arduino to the Spider or Cobra). I use the setting of 10ms between switch to transmit and transmit and 100ms between end of transmit and switch to receive for all transmitted messages. I have corrected the description in the previous post so that it no longer causes inaccuracies.

Well, and it's all clear why delays were necessary. Thanks for the explanation.
The communication was carefully described in terms of program execution, using the MAX485, and I was trying to understand it from the point of view of the behaviour of the signals on the Modbus bus.

In terms of the Modbus bus, this can be described simply:

Master - Cobra or Puma
Slave - Spider (address 5)
baudrate 9600

1 - Establishing communication
M - Query of slaves number 1 to 32 for 1 input register from address 0 (function 4)
S - Response returning value 054 147
2. GSM status query and furnace parameter changes
M - Request for 8 input registers starting from address 1 (function 4)
S - Response (for example 005 004 016 000 212 000 000 000 000 000 000 000 000 002 000 015 000 000 057 128)
3 - Sending furnace parameters and phone settings to Spider
M - send 40 registers starting from address 0 (function 16)
S - acknowledge writing of 40 registers
4 Receiving the currently stored cooker parameters in Spider
M - request 40 registers starting from address 0 (function 3)
S - response returning 80 bytes



The cyclic transmission from step 2 is required to maintain the connection between the devices. Without it, the modules find that there is no connection.

To control the cooker, messages from point 2 (transmitting settings to the cooker) and point 3 (receiving current settings and temperatures from the cooker) are required

I was wondering whether it would not be simpler, in the module connecting the Arduino to the RS485 bus, to permanently enable reception, i.e. to give an active signal to Receiver Enable (RE), and only when transmitting to activate Driver Enable (DE). In this case, admittedly, the Arduino receives everything that is on the Modbus bus, i.e. also echoes what it transmits itself, but this could even be beneficial. The Arduino in this case will never lose any message on the bus, and by listening to its echo it knows exactly when it has physically finished transmitting. Of the delays, only the one required by the Modbus specifications would remain, i.e. after receiving a message addressed to it, the Arduino would have to wait min. 3.5 Modbus characters. If it would be more convenient, instead of a timer, 4 bytes of arbitrary data could be sent for this purpose without activating the driver (DE). Own echo if not needed easily discarded.

I don't know how this module is connected to the Arduino, but I suppose it should be possible.

Added after 8 [minutes]: .

KonJarek wrote:

Messages from point 2 (transmitting settings to the furnace) and point 3 (receiving current settings and temperatures from the furnace)

are needed to control the furnace.

In this case, doesn't the master (Cobra) always still perform point 4, i.e. doesn't it query the "furnace parameters currently stored in Spider" and shouldn't these be exactly the same as those in point 3?

Gentlemen, you're being terribly charming.
The fact that the icon flashes in the controller is the result of faulty communication between the application<-->controller.
The controller, after a set period of time, determines a lack of communication which results in a flashing (warning) to the user of a possible module failure.

In order to get stabile communication, and here I do not have good news for you, you have to push the appropriate "code" on the relevant registers.
Some time ago I had a PC<->Cobra communication set up with my software. It worked for about 2 years. The project was almost 95% complete.
I think everything worked apart from the settings for 3D/4D.
I can't tell you the details of the communication, but I can give you directions/ideas

Just by using such a communication protocol as I have described above, Cobra does not raise an alarm about a lack of communication. It is sufficient that it receives appropriate responses to the messages sent.
You don't need to give details since they are so secret. All the necessary details are already given in the current thread because I see no reason to make such a secret of it. I can assure you that everything works beautifully. I am using this on a self-made panel.

Janiszew: I didn't notice your questions earlier, for this reason I will answer only now:
two-way communication is necessary for Cobra to see the connected module properly, not to mention sending settings. If, for example, the information from the Cobra is sufficient to display the current temperature of the cooker on the panel, you can turn a blind eye to the flashing alarm and receive a set of data from the transmission intended for the Buran module (054 146). Before you didn't lend me your Spider module, I used this to display temperatures on the room panel.

As for the second question, the answer with the same parameters is during normal furnace operation. It is only when you change the settings that there is a difference in these points, which is an indication that the cooker has not yet finished changing the settings. When the information from point 3 and point 4 coincide again, the Spider sets the zeros again in the answer from point 2 and thus the setting change procedure is completed.

Damian_lisu wrote:

Gentlemen, you are spellbinding terribly.
The fact that the icon is flashing in the controller is the result of faulty communication between the application<-->controller.
The controller, after a set period of time, determines that there is no communication which results in a flashing (warning) to the user of a possible module failure.

In order to get stabile communication, and here I do not have good news for you, you have to push the appropriate "code" on the relevant registers.
Some time ago I had a PC<->Cobra communication set up with my software. It worked for about 2 years. The project was almost 95% complete.
I think everything worked apart from the settings for 3D/4D.
I can't reveal the details of the communication, but I can direct/help with this

.

Despite my sincere intentions, unfortunately I have not been able to find any added value in this post, which is a pity .
If you can actually help or even direct with something, feel free to just do it for the electroda.pl community.
Everything that has been "conjured up" so far is the sole credit of KonJarek. I am firmly convinced that this is the only resource of knowledge on this subject made freely available to others. I would very much like to be wrong.

KonJarek wrote:

However, I was wrong. This second set of parameters is not for communication with the valve but with the Spider module.

The modules work in Modbus RTU, with a speed of 9600.
The communication looks like this:

1. Cobra sends a register request from address 0:
005 004 000 000 000 001 048 078
Spider responds with code 054 147:
005 004 002 054 147 031 061

(2) Cobra queries modem version and status (addresses 1-9):
005 004 000 001 000 008 161 136
Spider replies:
005 004 016 000 212 000 000 000 000 000 000 000 000 000 002 000 015 000 000 057 128
where:
005-module address
004 - Modbus message type
016 - number of returned bytes
000 212 - version 2.12
000 000 CH setting change
000 000 Change of HUW setting
000 000 1=start
000 000 1=stop
000 002 - modem status (001 - initialisation, 002-SIM error, 003-PIN error, 004-logging in, 005-logged in, 006-SMS error)
000 015 - GSM signal level
000 000 - ?
057 128 - CRC

The return of this message with a changed CH, DHW or start/stop setting temperature changes the Cobra settings.

Cobra saves the parameters to the module
005 016 000 000 040 080 000 000 002 172 002 158 000 255 001 003 000 002 000 039 000 080 000 000 001 043 052 056 XXX XXX XXX XXX XXX XXX 000 000 000 043
where:
005-address of module
016 - Modbus message type
000 000 - address of first register
040 080 - 40 registers, 80 bytes
000 000 - error codes (description at the bottom)
002 172 - CH temperature
002 158 - HUW temperature
000 255 - feeder temperature
001 003 - return temperature
000 002 - room thermostat status (0 - off, 1 - on, 2 - not working)
000 039 - set CO temperature
000 080 - set temperature of DHW
000 000 - whether controller is turned on (000 001 - on)
000 001 - whether the controller is off (works alternately with the previous register - only one of them is set to "1")
043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX 000 - first phone number stored in ASCII
000 000 000 043 052 000 000 - ??
043 052 056 049 049 049 049 049 049 048 000 - second telephone number recorded in ASCII (here +481111111110)
000 000 043 052 000 000 - ??
043 052 056 057 057 057 057 057 057 057 057 057 000 - third telephone number recorded in ASCII (here +489999999999)
000 000 - ??
068 - oven temperature in degrees (no fractional part)
000 000 000 - ??
112 134 - CRC

Error codes are in the form of flags. In the first byte, 5 lower bits can be set, in the second byte all 8. Setting several bits will send all set alarms in the text.
first byte:
bit 1 (1) - Large feeder current
bit 2 (2) - High DHW pump current
bit 3 (4) - CH pump high current
bit 4 (8) - Igniter high current
bit 5 (16) - Blower high current

second byte
bit 1 (1) - High boiler temperature
bit 2 (2) - Bin fire
bit 3 (4) - STB alarm
bit 4 (8) - Feeder blockade
bit 5 (16) - Fuel shortage
bit 6 (32) - Open hopper
bit 7 (64) - Bottom ash
bit 8 (128) - Temperature sensor fault

Spider confirms data storage:
005 016 000 000 000 040 193 147

4th Cobra queries 40 registers (first address 0):
005 003 000 000 000 040 068 172
Spider responds:
005 003 080 000 000 002 166 002 157 000 244 001 132 000 002 000 039 000 080 000 000
where:
005 - module address
003 - modbus message type
080 - number of returned bytes
000 000 - ??
002 166 - CH temperature
002 157 - HUW temperature
000 244 - feeder temperature
001 132 - return temperature
000 002 - room thermostat status
000 039 - preset CH temperature
000 080 - set HUW temperature
000 000 - whether controller is turned on (000 001 - on)
000 001 - whether the controller is off (alternates with the previous register - only one of them is set to "1")
043 052 056 XXX XXX XXX XXX XXX XXX XXX XXX 000 - first call
000 000 000 043 052 000 000 - ??
043 052 056 049 049 049 049 049 049 049 048 000 - second telephone
000 000 043 052 000 000 - ???
043 052 056 057 057 057 057 057 057 057 057 057 057 000 - third phone
000 - ???
000 067 - CO temperature in full degrees
000 000 000 - ??
242 018 - CRC

If there is no communication for more than one minute, the module sends last error messages and a "no communication with the controller" alarm

This is probably all that can be extracted from this device .

When communicating with Cobra, response times are very important. A delay of 100ms can result in the message being sent being rejected. After sending, you also need to add some time before switching to receive. When communicating with the Arduino, I set a 10ms delay before transmitting and 100ms at the end before switching the module to receive.

Hi. Has it been possible to control the cooker using the arduino? If so in what way? Using buttons? Some kind of app or from the computer? I was wondering if it would be possible to connect it to a supla and control, or at least view the temperature.

It is successful to the extent that you can control using the Spider module - setting temperatures, switching the boiler on/off. Parameter viewing is much more extensive - it is possible to read everything I described in sentence 016. For communication, you need an RS-485 module. It is enough to write a program that will confirm receipt of messages of types 003 and 004, receive and confirm message of type 016, check the checksum and, after its confirmation, select the necessary data from the message and transmit them to the display or to the computer. It is also possible to write a program for the computer and connect the RS-485 module via a USB-TTL converter without going through the Arduino. I use the Arduino because I want everything to be displayed on something like a room controller.

Have you tried putting it up on a website and controlling the temperature + controlling the settings remotely? Is there any chance you could put the program uploaded to the arduino? I would be very grateful

For the website I haven't tried it but it is rather doable. I already put the weather data from the Arduino on WUnderground and download the weather forecast from Weather.com to it. It is most convenient to do this over WIFI with the ESP8266 module, or instead of the Arduino use the ESP031 computer integrated with WIFI.
The whole program I used to test the connection with Cobra will be of no use to you, because without the Nextion display it won't work. I will try to extract the most important elements that you will incorporate into your own program. In general, this is no rocket science - it's all about communication over the serial port.

Super.
I've ordered an ESP8266 NodeMcu V3. If you shell out what you need we'll see if I can manage it

This is more or less what my test programme looked like. I'm not sure if there are errors in it now because I cut out the HMI support from it. I don't have time to test it now. It uses two serial ports so an arduino larger than UNO / pro mini is useful. I used a Mega 2560.




bool cobrareceived=false;
const byte nrster driver=5;
unsigned long t;
byte buforspider[80];
byte cobra[100];
byte bufor[100];
byte bufor2[100];byte cobralength=0;
byte variable1=0x36;
byte variable2=0x92;//0x93 - parameters for Spider module, 0x92 - extended furnace parameters
uint16_t crc;
void setup() {
Serial.begin(115200);//PC
Serial2.begin(9600);//RS485
pinMode(3,OUTPUT);//RS485 R W
digitalWrite(3,LOW);
};

void loop() {
while(Serial2.available()){
t=millis();
receive=true;
newsign=true;
buffer[bufpos]=Serial2.read();
bufpos++;
if(bufpos>6){
switch (bufpos[1]){
case 3:
cobralength=8;
break;
case 4:
cobralength=8;
break;
case 16:
cobralength=9+bufor[6];
break;
default:
break;
}
if(bufpos==cobralength){
crc=CRC16(bufpos,bufpos-2);
if((bufor[bufpos-2]==(crc&0xFF))&&(bufor[bufpos-1]==(crc>>8))){
if(buffer[0]==controller number){
for(byte i=0;i<cobralength;i++){
if(buffer[i]<100){
Serial.print("0");
}
if(buffer[i]<10){
Serial.print("0");
}
Serial.print(bufor[i]);
Serial.print(" ");
}
Serial.print(" CRC OK");
cobrareceived=true;
}
if(buffer[1]==16){
for (byte i=0;i<80;i++){
buforspider[i]=bufor[7+i];
}
Serial.println("buffer filled");
mamdane=true;
}
}else{
for(byte i=0;i<cobralength;i++){
if(buffer[i]<100){
Serial.print("0");
}
if(buffer[i]<10){
Serial.print("0");
}
Serial.print(bufor[i]);
Serial.print(" ");
}
Serial.print(" CRC BAD, should be ");
cobrareceived=true;
Serial.print(crc&0xFF);
Serial.print(":");
Serial.print(crc>>8);
}
if(bufpos>0){
bufpos=0;
cobralength=0;
Serial.println();
}
}
}
}
if(cobrareceived){
switch(buffer[1]){
case 3:
{ if(mamdane){
digitalWrite(3,HIGH);
delay(10);
bufor2[0]=bufor[0];
bufor2[1]=0x03;
bufor2[2]=80;
for(byte i=0;i<80;i++){
bufor2[3+i]=buforspider[i];
}
bufor2[83]=(CRC16(bufor2,83)&0xFF);
bufor2[84]=(CRC16(bufor2,83)>>8);

for( byte i=0;i<85;i++){
if(bufor2[i]<100){
Serial.print("0");
}
if(bufor2[i]<10){
Serial.print("0");
}
Serial.print(bufor2[i]);
Serial2.write(bufor2[i]);
Serial.print(" ");
}
Serial.println();
delay(100);
digitalWrite(3,LOW);
}
break;
case 4:
if(buffer[3]==0){
digitalWrite(3,HIGH);
delay(10);
bufor2[0]=bufor[0];
buffer2[1]=(0x04);
bufor2[2]=(0x02);
buffer2[3]=(variable1);
buffer2[4]=(variable2);
bufor2[5]=(CRC16(bufor2,5)&0xFF);
bufor2[6]=(CRC16(bufor2,5)>>8);
delay(100);

for( byte i=0;i<7;i++){
if(bufor2[i]<100){
Serial.print("0");
}
if(bufor2[i]<10){
Serial.print("0");
}
Serial.print(bufor2[i]);
Serial2.write(bufor2[i]);
Serial.print(" ");
}

Serial.println();
delay(100);
digitalWrite(3,LOW);
}
if(buffer[3]==1){
digitalWrite(3,HIGH);
delay(10);
bufor2[0]=bufor[0];
bufor2[1]=0x04;
bufor2[2]=16;
bufor2[3]=0;
buffer2[4]=101;
buffer2[5]=0;
buffer2[6]=0;
buffer2[7]=0;
if(mamdane&&buforspider[15]==65){
buffer2[8]=80;
}else{
bufor2[8]=0;
}
buffer2[9]=0;
buffer2[10]=0;
buffer2[11]=0;
buffer2[12]=0;
buffer2[13]=0;
buffer2[14]=5;
buffer2[15]=0;
buffer2[16]=25;
buffer2[17]=0;
buffer2[18]=0;
bufor2[19]=(CRC16(bufor2,19)&0xFF);
bufor2[20]=(CRC16(bufor2,19)>>8);

for( byte i=0;i<21;i++){
Serial.print(buffer2[i]);
Serial2.write(bufor2[i]);
Serial.print(" ");
}
delay(100);
digitalWrite(3,LOW);
Serial.println();
}

break;
case 10:
break;
case 16:
// z=bufor[6];
for(byte j=0;j<bufor[6];j++){
cobra[j]=bufor[j+7];
}
write();
digitalWrite(3,HIGH);
delay(100);
buffer2[0]=bufor[0];
bufor2[1]=(0x10);
bufor2[2]=(0x00);
bufor2[3]=(0x00);
buffer2[4]=(0x00);
buffer2[5]=bufor[5];
bufor2[6]=(CRC16(bufor2,6)&0xFF);
bufor2[7]=(CRC16(bufor2,6)>>8);

for( byte i=0;i<8;i++){
Serial.print(buffer2[i]);
Serial2.write(bufor2[i]);
Serial.print(" ");
}
Serial.println();
delay(6);
digitalWrite(3,LOW);
break;
}
cobrareceived=false
}


if(((millis()-t)>600)&&(receive)){
// Serial.println("<<timeout>>");
receive=false;
bufpos=0;
cobralength=0;
}
}

uint16_t CRC16(byte buf[], int len)
{
uint16_t crc = 0xFFFF;

for (int pos = 0; pos < len; pos++)
{
crc ^= (uint16_t)buf[pos]; // XOR byte into least sig. byte of crc

for (int i = 8; i != 0; i--) { // Loop over each bit
if ((crc & 0x0001) != 0) { // If the LSB is set
crc >>= 1; // Shift right and XOR 0xA001
crc ^= 0xA001;
}
else // Else LSB is not set
crc >>= 1; // Just shift right
}
}
// Note, this number has low and high bytes swapped, so use it accordingly (or swap bytes)
return crc;
}
void write(){
float help;
Serial.print("driver parameters :");
Serial.print("Data: ");Serial.print(cobra[0]);Serial.print("/");Serial.print(cobra[1]);Serial.print("/");Serial.print(cobra[2]);Serial.print(" ");
Serial.print("/");Serial.print(cobra[3]);Serial.print(":");Serial.print(cobra[4]);Serial.print(":");Serial.print(cobra[5]);Serial.print(" ");
pomoc=cobra[6]*256+cobra[7];
Serial.print("\nTemp. CO ");Serial.print(help/10);
pomoc=cobra[8]*256+cobra[9];
Serial.print("\nTemp. DHW ");Serial.print(help/10);
pomoc=cobra[10]*256+cobra[11];
Serial.print("\nTemp. sub. ");Serial.print(help/10);
pomoc=cobra[12]*256+cobra[13];
Serial.print("\nTemp. back. ");Serial.print(help/10);
Serial.print("\n???? ");Serial.print(cobra[14]);
Serial.print("\n???? ");Serial.print(cobra[15]);
Serial.print("\n???? ");Serial.print(cobra[16]);
Serial.print("\n???? ");Serial.print(cobra[17]);
Serial.print("\n???? ");Serial.print(cobra[18]);
Serial.print("\nnadmuch ");Serial.print(cobra[19]);
Serial.print("\n???? ");Serial.print(cobra[20]);
if((cobra[21]&0b1000)==0b1000){
Serial.print("cobra ON");
}else{
Serial.print("Controller OFF");
}
if((cobra[21]!=0)&&(cobra[21]!=8)){
Serial.print(" value unknown :");
Serial.print(cobra[21]);
}
Serial.print("\n???? ");Serial.print(cobra[22]);
if(cobra[23]>39){
Serial.print("\nTemp. CO ");Serial.print(cobra[23]);
}else{
Serial.print("CO OFF");
}
Serial.print("\n???? ");Serial.print(cobra[24]);
if(cobra[25]>39){
Serial.print("\nTemp. CWU ");Serial.print(cobra[25]);
}else{
Serial.print("CWU OFF");
}
Serial.print("\n???? ");Serial.print(cobra[26]);
Serial.print("\n???? ");Serial.print(cobra[27]);
Serial.print("\n???? ");Serial.print(cobra[28]);
Serial.print("PID ");
if((cobra[29]&0b01110000)==0b01000000){
Serial.print("OFF ");
}
if((cobra[29]&0b01110000)==0b01010000){
Serial.print("PID ");
}
if((cobra[29]&0b01110000)==0b01100000){
Serial.print("ADC ");
}
if((cobra[29]!=105)&&(cobra[29]!=89)&&(cobra[29]!=73)){
Serial.print(" value unknown :");
Serial.print(cobra[29]);
}
Serial.print("\n???? ");Serial.print(cobra[30]);
Serial.print("Feeder break ");Serial.print(cobra[31]);
Serial.print("\n???? ");Serial.print(cobra[32]);
Serial.print("\nMax. pred. went. ");Serial.print(cobra[33]);
Serial.print("\n???? ");Serial.print(cobra[34]);
Serial.print("\nThe power of the furnace ");Serial.print(cobra[35]);
Serial.print("\n???? ");Serial.print(cobra[36]);
Serial.print("\n???? ");Serial.print(cobra[37]);
Serial.print("\n???? ");Serial.print(cobra[38]);
Serial.print("\n???? ");Serial.print(cobra[39]);
}

Added after 16 [minutes]:

As for the ESP 8266 then the following AT codes need to be used:

"AT" - to check if there is a connection to the module. It should answer "OK"
"AT+CIPMUX=0" - setting the single connection mode. It should reply "OK". I haven't tried multi mode yet, but given that my computer reads time from NTP, sends weather data and receives forecasts, I may use multi at some point.
"AT+CWMODE=1" - setting client mode. It should reply "OK." If it answers "link is built", it means it is already connected.
"AT+CWJAP="" SSID "ƒ"" password "ƒ"" - connection to the router. It should reply "OK"
"AT+CIPSTART=\"TCP\",\"wxdata.weather.com\",80" - connection, in my case to Weather.com. It should reply "OK"
"AT+CIPSEND=110" - specifying the length of the data to be transmitted. Should reply ">"
"GET /wxdata/weather/local/PLXX6385?cc=%2A&unit=m&dayf=2&locale=en HTTP/1.1Host: wxdata.weather.com". - request for data from the site. After transmission, we are waiting for a response starting with "+IPD"

Simply send the appropriate commands and wait for responses or error messages. There may be different firmwares in the ESP so the commands and responses may vary a little.

Thanks a lot. I might be able to make something out of it. The Arduino Mega is already coming from China.

Hello,

sorry for my bad polish, but I live in Germany and use google translator.
I bought a pellet heater with PUMA PID and am very happy with it. Unfortunately in Germany it is mandatory to have a buffer tank of at least 1000 litres when heating with pellets. But now it is the case that the PUMA PID always keeps the kettle at the right temperature and I don't want that. I am looking for a way to disable the PUMA PID without pulling the plug.

However, the above protocol looks different from mine. There is a USB stick available with MAX485, Arduinos and Raspberry PI. I would be interested in a Python solution here.


Thank you for your time

Regards Michal