No serial communication after successful board programming. nanoCUL board advice needed about evofw3 HOT 10 CLOSED

FYI Terminal configurations are:

Via Arduino IDE:
/dev/cu.usbserial-A50285BI
Speed 115200

Via Terminal:
/dev/cu.usbserial-A50285BI
Speed 15200
Bits 8
Stop Bits 1
Parity N

similar for screen

from evofw3.

from evofw3.

Reloaded with Pinout set to "Pro" same result - no communication, see image below. Also tried "Old Bootloader" and that failed for the upload. "Standard Bootloader" works (completed upload with no error).

from evofw3.

from evofw3.

Doh - That would be it then!

More information below for others that may find it useful.

My mistake was thinking that the board definition

https://raw.githubusercontent.com/ghoti57/evofw3_avr/master/package_evofw3_boards_index.json

took the code as well (as it pointed to a .gz file. (I'm new to Arduino IDE)

So I downloaded evofw3-master and then

1. Opened the evofw3.ino file in Arduino IDE
2. Sketch -> Verify/Compile
3. Sketch -> Upload (tool a little longer this time :)
4. Tools -> Serial Monitor

Now receiving output like this!:

evofw3 0.7.1
068 I --- 01:073314 --:------ 01:073314 1F09 003 FF050F
068 I --- 01:073314 --:------ 01:073314 30C9 027 0007000106CD0208550307CE0407A705078C0607C107076108067B
067 I --- 01:073314 --:------ 01:073314 0008 002 FA00
080 RQ --- 30:220186 63:262143 --:------ 3EF0 001 00
080 RQ --- 30:220186 63:262143 --:------ 3EF0 001 00
081 RQ --- 30:220186 63:262143 --:------ 3EF0 001 00
080 RQ --- 30:220186 01:073314 --:------ 0006 001 00
065 RP --- 01:073314 30:220186 --:------ 0006 004 00050000
061 I --- 22:042643 --:------ 22:042643 0008 002 0000
062 I --- 22:042643 --:------ 22:042643 0008 002 0000

Next step - work out what's what!

Many thanks for your help,

Grish

from evofw3.

So it's decoding like a champ now!

How "talkative" is Evohome in general? I'm getting messages (sometimes a few of them quickly) every few seconds. Sometimes messages do not come through for up to 20 seconds. (Roughly 1 out of 10 messages or batches has a delay up to roughly 20 seconds). In general its 6 to 20 messages per minute. The heating is turned off now.

I may be missing messages, which is not a problem and I understand this will happen.

My question:

Is this "normal" traffic, or should I consider running the tuning routine for the C1101 (as shown in the wiki)?

My thinking is this traffic is pretty good, but with no experience with this I thought I'd ask.

Many thanks for the code!

Grish

from evofw3.

If you haven't done so jet check out the evohome_cc, evohome_rf links on this page
https://indalo-tech.onlineweb.shop/SSM-D2/p7844707_21584696.aspx
The dev has a lot of background information in his github wikis

The tuning algorithm was only created to deal with a batch of particularly dodgy cc1101 modules that appeared in late 2020.
They had inaccurate crystals. I can't remember who was actually selling them (but they were from Germany).
You don't need to run it unless you really think there's a lot of missing messages or TX is not working very well.

The atm328p devices are fundamentally poorer in RX of messages than atm32u4 based devices - they will drop more messages. This is because they don't have an available HW UART to interface to the cc1101. Both families of device should TX equally well subject to having an accurate cc1101 crystal.

The number of messages depends on the number of devices in your system.
You'll see a burst of activity every 3-4 minutes (random interval set by controller) where battery operated devices get updated and respond.

Mains powered devices (BDR91 etc) are not tied to this time interval.

from evofw3.

I've looked back at the issue that led to me writing autotune.
The devices with the faulty crystal came from the same place as your device.

The crystal has most impact on TX.
You can test this by sending a message to the controller from the Arduino Serial Monitor.

make sure you have line ending set to CR+LF and then try to send this command
RQ --- 18:730 01:073314 --:------ 0016 001 00

18:730 is a pseudo address for your gateway (usb device). You'll see it's real address in the reply.
01:073314 is your controller address (taken from the log sample above)

The controller should always respond - the last value of the RP from the controller is the received signal strength seen by the controller (hex) The value before RPis the received signal strength at the gateway (decimal)

Smaller values are better. Depending on how far you are from your controller the values in your log sample above don't look too bad.

from evofw3.

Funny - I initially tried to purchase the device from there (local in the UK), but they were out of stock - so I got this one from Germany. Incidentally, the one I received has a SMA connector for an antenna (also supplied). The antenna is pretty "tall" for 868Mhz - about 3 inches long - maybe they started fixing antennas to them as the coil of wire was so-so in terms of working (compounding the crystal issue?)

I see that the signal strength that devices report are between 050-086 so I'm happy enough with the receive.

If I understand you right, the tuning is mainly for transmit. Looks like that is working - here is the test result:
000 RQ --- 18:068639 01:073314 --:------ 0016 001 00
065 RP --- 01:073314 18:068639 --:------ 0016 002 0018

So a 65 signal strength? That'll do fine!

The following is informational only/comment - I'm up and running - thank you for your help.

(BTW - am I suppose to close this ticket?? as its resolved :)

There are 18 devices (not including null and the nanoCUL) on the system and I've found them all:
TRVs (9)
Controller (1 :) )
Gateway (1)
DHW sensor (1)
DTS92E (3)
BDR91 (3) - (Boiler relay, UFH relay, and I think the system pump relay)

Just have to work out which TRV is where, which DTS92E is where and what the BDR91s are for.

Assuming the BDR91 that controls the boiler is the one sending the "3EF0" codes and that those messages will be the firing times for the boiler - OFF="0000FF" and ON="00C8FF", but will have a look at ramses_cc board to see if there is any advice to see if that is the best method for determining firing times.

Also assuming gas is burned at the same rate always - its either burning or its not (not a combi boiler). So if I can figure the volume/minute burned, I'll know how much is spent daily/weekly +/- some percent.

BTW - I've had this Honeywell system for 14 years. It's been great to have individual room programs over the years, but always lacked the control and extra information that makes it really useful. Glad I found this project (even if its been a while since you started it) - many thanks for your work!

Grish

from evofw3.

from evofw3.