Setting controller mode or set point not working from Domoticz

[FrankvdAa]

Hi,

I bought a NanoCUL a few months back to be able to control my Evohome from Domoticz.

Have been able to discover all valve, but I'm not able to set the controller mode (normal, economy, off, ...) or set points.

I do see Domoticz sending the command, but don't see any response to that:

000 W --- 18:003618 01:204708 --:------ 2E04 008 01FFFFFFFFFFFF00 000 W --- 18:003618 01:204708 --:------ 2E04 008 00FFFFFFFFFFFF00

Somebody I know has a real HGI80 and he sees the following when changing controller mode:

095 W --- 18:012786 01:072015 --:------ 2E04 008 01FFFFFFFFFFFF00 049 I --- 01:072015 --:------ 01:072015 2E04 008 01FFFFFFFFFFFF00 047 I --- 01:072015 01:072015 --:------ 2E04 008 01FFFFFFFFFFFF00 095 W --- 18:012786 01:072015 --:------ 2E04 008 00FFFFFFFFFFFF00 049 I --- 01:072015 --:------ 01:072015 2E04 008 00FFFFFFFFFFFF00 047 I --- 01:072015 01:072015 --:------ 2E04 008 00FFFFFFFFFFFF00

Not sure what the three digits at the beginning of each line represent, but I noticed that in my setup it's always 000 when the second column is showing 'W'.

I understood that TX should be working with the latest firmware, or am I wrong?

Please let me know if you need me to run any tests or in case you need more information.

Thanks,

Frank

[FrankvdAa]

Snippet of a log from earlier today:

21:20:17.898 # evohome_rf 0.5.5 21:20:17.951 PktProtocolQos.send_data( I|63:262142|0001|00): boff=0, want= I|63:262142|0001|00, tout=2021-02-15 21:20:18.001519: RE-SENT (1/24) 21:20:18.004 PktProtocolQos.send_data( I|63:262142|0001|00): boff=0, want= I|63:262142|0001|00, tout=2021-02-15 21:20:18.054074: RE-SENT (2/24) 21:20:18.056 PktProtocolQos.send_data( I|63:262142|0001|00): boff=0, want= I|63:262142|0001|00, tout=2021-02-15 21:20:18.106414: RE-SENT (3/24) 21:20:18.109 PktProtocolQos.send_data( I|63:262142|0001|00): boff=0, want= I|63:262142|0001|00, tout=2021-02-15 21:20:18.158841: RE-SENT (4/24) 21:20:18.161 PktProtocolQos.send_data( I|63:262142|0001|00): boff=0, want= I|63:262142|0001|00, tout=2021-02-15 21:20:18.211265: RE-SENT (5/24) 21:20:18.181 # evofw3 0.6.7 21:20:18.213 PktProtocolQos.send_data( I|63:262142|0001|00): boff=0, want= I|63:262142|0001|00, tout=2021-02-15 21:20:18.263730: RE-SENT (6/24) 21:20:18.256 || HGI:003618 | NUL:262142 | I | rf_unknown | 00FFF... || {'unknown_0': 'FFFF', 'unknown_1': '02', 'unknown_2': '00'} 21:20:43.900 || CTL:204708 | OTB:030173 | RQ | actuator_state | 00 || {} 21:20:43.932 || OTB:030173 | CTL:204708 | RP | actuator_state | 00001... || {'actuator_enabled': False, 'modulation_level': 0.0, '_unknown_0': '10', 'flame_active': True, 'flame_state': '0A', '_unknown_1': '00FF033D64'} 21:20:43.965 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {} 21:20:44.166 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=1, want=RQ|01:204708|10E0|00, tout=2021-02-15 21:20:44.266409: RE-SENT (1/3) 21:20:44.204 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {} 21:20:44.611 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=2, want=RQ|01:204708|10E0|00, tout=2021-02-15 21:20:44.810766: RE-SENT (2/3) 21:20:44.636 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {} 21:20:45.443 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=3, want=RQ|01:204708|10E0|00, tout=2021-02-15 21:20:45.843070: RE-SENT (3/3) 21:20:45.485 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {} 21:20:47.090 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=3, want=RP|01:204708|10E0|00, tout=2021-02-15 21:20:47.086022: EXPIRED 21:20:47.132 || HGI:003618 | CTL:204708 | RQ | zone_devices | 000D || {'domain_id': 'FA', 'device_class': 'hotwater_sensor'} 21:20:47.337 PktProtocolQos.send_data(RQ|01:204708|000C|000D): boff=1, want=RQ|01:204708|000C|000D, tout=2021-02-15 21:20:47.437286: RE-SENT (1/3) 21:20:47.372 || HGI:003618 | CTL:204708 | RQ | zone_devices | 000D || {'domain_id': 'FA', 'device_class': 'hotwater_sensor'} 21:20:47.775 PktProtocolQos.send_data(RQ|01:204708|000C|000D): boff=2, want=RQ|01:204708|000C|000D, tout=2021-02-15 21:20:47.975276: RE-SENT (2/3) 21:20:47.803 || HGI:003618 | CTL:204708 | RQ | zone_devices | 000D || {'domain_id': 'FA', 'device_class': 'hotwater_sensor'} 21:20:48.609 PktProtocolQos.send_data(RQ|01:204708|000C|000D): boff=3, want=RQ|01:204708|000C|000D, tout=2021-02-15 21:20:49.008708: RE-SENT (3/3) 21:20:48.635 || HGI:003618 | CTL:204708 | RQ | zone_devices | 000D || {'domain_id': 'FA', 'device_class': 'hotwater_sensor'} 21:20:50.241 PktProtocolQos.send_data(RQ|01:204708|000C|000D): boff=3, want=RP|01:204708|000C|000D, tout=2021-02-15 21:20:50.236423: EXPIRED 21:20:50.283 || HGI:003618 | CTL:204708 | RQ | zone_devices | 000F || {'domain_id': 'FC', 'device_class': 'heating_control'} 21:20:50.488 PktProtocolQos.send_data(RQ|01:204708|000C|000F): boff=1, want=RQ|01:204708|000C|000F, tout=2021-02-15 21:20:50.588503: RE-SENT (1/3) 21:20:50.523 || HGI:003618 | CTL:204708 | RQ | zone_devices | 000F || {'domain_id': 'FC', 'device_class': 'heating_control'} 21:20:50.928 PktProtocolQos.send_data(RQ|01:204708|000C|000F): boff=2, want=RQ|01:204708|000C|000F, tout=2021-02-15 21:20:51.128277: RE-SENT (2/3) 21:20:50.955 || HGI:003618 | CTL:204708 | RQ | zone_devices | 000F || {'domain_id': 'FC', 'device_class': 'heating_control'} 21:20:51.758 PktProtocolQos.send_data(RQ|01:204708|000C|000F): boff=3, want=RQ|01:204708|000C|000F, tout=2021-02-15 21:20:52.158372: RE-SENT (3/3) 21:20:51.787 || HGI:003618 | CTL:204708 | RQ | zone_devices | 000F || {'domain_id': 'FC', 'device_class': 'heating_control'} 21:20:52.187 || STA:038973 | | I | temperature | 000782 || {'temperature': 19.22} 21:20:53.790 PktProtocolQos.send_data(RQ|01:204708|000C|000F): boff=3, want=RP|01:204708|000C|000F, tout=2021-02-15 21:20:53.788475: EXPIRED 21:20:53.819 || HGI:003618 | CTL:204708 | RQ | tpi_params | FC || {'domain_id': 'FC'} 21:20:54.024 PktProtocolQos.send_data(RQ|01:204708|1100|FC): boff=1, want=RQ|01:204708|1100|FC, tout=2021-02-15 21:20:54.123907: RE-SENT (1/3) 21:20:54.058 || HGI:003618 | CTL:204708 | RQ | tpi_params | FC || {'domain_id': 'FC'} 21:20:54.464 PktProtocolQos.send_data(RQ|01:204708|1100|FC): boff=2, want=RQ|01:204708|1100|FC, tout=2021-02-15 21:20:54.664364: RE-SENT (2/3) 21:20:54.491 || HGI:003618 | CTL:204708 | RQ | tpi_params | FC || {'domain_id': 'FC'} 21:20:55.296 PktProtocolQos.send_data(RQ|01:204708|1100|FC): boff=3, want=RQ|01:204708|1100|FC, tout=2021-02-15 21:20:55.696537: RE-SENT (3/3) 21:20:55.322 || HGI:003618 | CTL:204708 | RQ | tpi_params | FC || {'domain_id': 'FC'} 21:20:56.927 PktProtocolQos.send_data(RQ|01:204708|1100|FC): boff=3, want=RP|01:204708|1100|FC, tout=2021-02-15 21:20:56.923082: EXPIRED 21:20:56.954 || HGI:003618 | CTL:204708 | RQ | datetime | 00 || {} 21:20:57.156 PktProtocolQos.send_data(RQ|01:204708|313F|00): boff=1, want=RQ|01:204708|313F|00, tout=2021-02-15 21:20:57.255746: RE-SENT (1/3) 21:20:57.194 || HGI:003618 | CTL:204708 | RQ | datetime | 00 || {} 21:20:57.596 PktProtocolQos.send_data(RQ|01:204708|313F|00): boff=2, want=RQ|01:204708|313F|00, tout=2021-02-15 21:20:57.796226: RE-SENT (2/3) 21:20:57.626 || HGI:003618 | CTL:204708 | RQ | datetime | 00 || {} 21:20:58.432 PktProtocolQos.send_data(RQ|01:204708|313F|00): boff=3, want=RQ|01:204708|313F|00, tout=2021-02-15 21:20:58.832301: RE-SENT (3/3) 21:20:58.458 || HGI:003618 | CTL:204708 | RQ | datetime | 00 || {} 21:21:00.064 PktProtocolQos.send_data(RQ|01:204708|313F|00): boff=3, want=RP|01:204708|313F|00, tout=2021-02-15 21:21:00.059011: EXPIRED 21:21:00.105 || HGI:003618 | CTL:204708 | RQ | system_zones | 0008 || {'zone_type': 'radiator_valve'} 21:21:00.309 PktProtocolQos.send_data(RQ|01:204708|0005|0008): boff=1, want=RQ|01:204708|0005|0008, tout=2021-02-15 21:21:00.409488: RE-SENT (1/3) 21:21:00.346 || HGI:003618 | CTL:204708 | RQ | system_zones | 0008 || {'zone_type': 'radiator_valve'}

[ghoti57]

If either of you can get an analyser a pulseview trace of GDO0/GDO2 + MOSI/SCK/MISO/CSN will help. Sample at 1MHZ. collect as many samples as possible. Start the capture and then press the nano reset. Try to send something (from serial monitor) as soon as possible. Stop capture

[iMiMx]

evo_HA.log

[ghoti57]

@zxdavb I don't think TX is working. Are you aware of anyone who's used this module successfully?

[danrp-git]

Having the same problem, also brought via eBay German reseller.

[zxdavb]

This is definitely a problem - looks like to echo from evofw3:

21:20:44.166 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=1, want=RQ|01:204708|10E0|00, tout=2021-02-15 21:20:44.266409: RE-SENT (1/3)
21:20:44.204 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {}
21:20:44.611 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=2, want=RQ|01:204708|10E0|00, tout=2021-02-15 21:20:44.810766: RE-SENT (2/3)
21:20:44.636 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {}
21:20:45.443 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=3, want=RQ|01:204708|10E0|00, tout=2021-02-15 21:20:45.843070: RE-SENT (3/3)
21:20:45.485 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {}
21:20:47.090 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=3, want=RP|01:204708|10E0|00, tout=2021-02-15 21:20:47.086022: EXPIRED

[danrp-git]

2021-02-15 21:30:06 WARNING (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:045348|1100|00): boff=1, want=RQ|13:045348|1100|00, tout=2021-02-15 21:30:06.619783: RE-SENT (1/3) 2021-02-15 21:30:06 WARNING (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:045348|1100|00): boff=2, want=RQ|13:045348|1100|00, tout=2021-02-15 21:30:07.147745: RE-SENT (2/3) 2021-02-15 21:30:07 WARNING (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:045348|1100|00): boff=3, want=RQ|13:045348|1100|00, tout=2021-02-15 21:30:08.178980: RE-SENT (3/3)

[ghoti57]

@danrp-git smart-home-komponente?

[danrp-git]

Yes

[zxdavb]

What do you mean by 'this module' - I do not usually pay attention to HW layer - I have people who do that for me. :)

[ghoti57]

the smart-home-komponente nanoCUL

[FrankvdAa]

@danrp-git smart-home-komponente?

Yes

[danrp-git]

https://www.ebay.co.uk/itm/372221622516

[zxdavb]

https://www.ebay.co.uk/itm/372221622516

That is the exact one I have

[ghoti57]

So there's nothing fundamentally wrong with the hardware and evofw3 works on it. Suggests there's a HW fault.

[domb80]

Hi, I also have one of these devices. Seeing very similar in HA using evhome_cc and evohome_rf. After a long time it manages to listen to enough packets to populate my device attributes, but TX seems a bit weird. Sometimes I can set a setpoint, but it very rarely works.

[zxdavb]

After a long time it manages to listen to enough packets to populate my device attribute

This intimates packets are being received (the nanoCUL is eavesdropping) but not discovering.

[danrp-git]

Running mine through a Pi 4, could it be a power limit via the USB port?

After a long time it manages to listen to enough packets to populate my device attribute

This intimates packets are being received (the nanoCUL is eavesdropping) but not discovering.

Same behaviour.

[zxdavb]

Suggests there's a HW fault.

But >1 person having same issue:

• bad batch from HW supplier?
  • issue with arduino settings?

[domb80]

Agreed, just seems a bit weird sometimes a setpoint works on the climate entity. But in general it seems to be really struggling even in the same room as the controller or HR92 in question. Same ebay seller as above, received today.

[ghoti57]

Can anyone take a closeup picture of the cc1101 module connections

[danrp-git]

Running a controller discovery...

bash-5.0# python -O client.py -rr execute /dev/ttyUSB0 -sf 01:210309 -o scan_full.log

client.py: Starting evohome_rf... 21:50:52.219 scan_full() invoked - expect a lot of Warnings 21:50:52.231 # evohome_rf 0.5.5 21:50:52.284 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.333989: RE-SENT (1/24) 21:50:52.335 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.384834: RE-SENT (2/24) 21:50:52.386 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.436222: RE-SENT (3/24) 21:50:52.438 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.488405: RE-SENT (4/24) 21:50:52.491 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.541523: RE-SENT (5/24) 21:50:52.545 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.595633: RE-SENT (6/24) 21:50:52.600 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.650346: RE-SENT (7/24) 21:50:52.655 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.705595: RE-SENT (8/24) 21:50:52.711 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.760784: RE-SENT (9/24) 21:50:52.712 # F 21:50:52.767 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.816831: RE-SENT (10/24) 21:50:52.821 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:50:52.871210: RE-SENT (11/24)

[domb80]

Running mine through a Pi 4, could it be a power limit via the USB port?

After a long time it manages to listen to enough packets to populate my device attribute

This intimates packets are being received (the nanoCUL is eavesdropping) but not discovering.

Same behaviour.

I am getting the same on both a Pi4 and a x86 ESXi host. I think loads of folk run these on pi4?

[Gamelauncher]

Just updated my botched together nano + cc1101 ( home-brew ) and evohome_rf and don't have any problems to rule out programming bug.

Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.protocol] MsgTransport.pkt_dispatcher(RQ --- 18:000730 01:132956 --:------ 0004 002 0200): send_data Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 INFO (MainThread) [custom_components.evohome_cc.evohome_rf.transport] PktProtocolQos.send_data(RQ --- 18:000730 01:132956 --:------ 0004 002 0200) Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.protocol] MsgTransport.write(RQ --- 18:000730 01:132956 --:------ 000C 002 0208) Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.protocol] MsgTransport.get_write_buffer_size() Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.protocol] MsgProtocol.pause_writing() Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 INFO (MainThread) [custom_components.evohome_cc.evohome_rf.transport] PktProtocolQos.data_rcvd(b'000 RQ --- 18:075787 01:132956 --:------ 0004 002 0200') Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.transport] PktProtocolQos.data_rcvd(RQ|01:132956|0004|02): boff=0, want=RP|01:132956|0004|02, tout=2021-02-15 23:45:02.926060: CHECKED - matched the Tx pkt (now wanting a Rx pkt) Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.protocol] MsgTransport._pkt_receiver(000 RQ --- 18:075787 01:132956 --:------ 0004 002 0200) Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.protocol] MsgProtocol.data_received(|| HGI:075787 | CTL:132956 | RQ | zone_name | 0200 || {'zone_idx': '02'}) Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 INFO (MainThread) [custom_components.evohome_cc.evohome_rf.transport] PktProtocolQos.data_rcvd(b'044 RP --- 01:132956 18:075787 --:------ 0004 022 0200426564726F6F6D00000000000000000000000000') Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.transport] PktProtocolQos.data_rcvd(RP|01:132956|0004|02): boff=0, want=None, tout=2021-02-15 23:45:02.926060: CHECKED - matched the Rx pkt - now done Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.protocol] MsgTransport._pkt_receiver(044 RP --- 01:132956 18:075787 --:------ 0004 022 0200426564726F6F6D00000000000000000000000000) Feb 15 23:45:02 hassbian hass[30001]: 2021-02-15 23:45:02 DEBUG (MainThread) [custom_components.evohome_cc.evohome_rf.protocol] MsgProtocol.data_received(|| CTL:132956 | HGI:075787 | RP | zone_name | 02004... || {'zone_idx': '02', 'name': 'Bedroom'})

[ghoti57]

Suggests there's a HW fault.

But >1 person having same issue:

• bad batch from HW supplier?
• issue with arduino settings?

Since RX is working arduino settings must be correct - otherwise your's wouldn't work either

[FrankvdAa]

Can anyone take a closeup picture of the cc1101 module connections

How close do you want it? This is the best I can get it.

[zxdavb]

This is a better command to try:

python -O client.py -rr execute /dev/ttyUSB0 -sd 01:210309 -o scan_disc.log

Will only send RQs where a RP is expected.

[danrp-git]

python -O client.py -rr execute /dev/ttyUSB0 -sd 01:210309 -o scan_disc.log

21:59:56.387 # evohome_rf 0.5.5 21:59:56.392 # evofw3 0.6.7 21:59:56.444 PktProtocolQos.send_data( I|63:262142|7FFF|00): boff=0, want= I|63:262142|7FFF|00, tout=2021-02-15 21:59:56.494226: RE-SENT (1/24) 21:59:56.446 || HGI:140073 | NUL:262142 | I | puzzle_packet | 00002... || {'datetime': '0021-02-15T21:59 21:59:56.480 || HGI:140073 | CTL:210309 | RQ | rf_check | 00FF || {'zone_idx': '00'} 21:59:56.681 PktProtocolQos.send_data(RQ|01:210309|0016|00): boff=1, want=RQ|01:210309|0016|00, tout=2021-02-15 21:59:56.781227: RE-SENT (1/5) 21:59:56.708 || HGI:140073 | CTL:210309 | RQ | rf_check | 00FF || {'zone_idx': '00'} 21:59:57.109 PktProtocolQos.send_data(RQ|01:210309|0016|00): boff=2, want=RQ|01:210309|0016|00, tout=2021-02-15 21:59:57.309522: RE-SENT (2/5) 21:59:57.138 || HGI:140073 | CTL:210309 | RQ | rf_check | 00FF || {'zone_idx': '00'} 21:59:57.941 PktProtocolQos.send_data(RQ|01:210309|0016|00): boff=3, want=RQ|01:210309|0016|00, tout=2021-02-15 21:59:58.340918: RE-SENT (3/5) 21:59:57.968 || HGI:140073 | CTL:210309 | RQ | rf_check | 00FF || {'zone_idx': '00'} 21:59:59.572 PktProtocolQos.send_data(RQ|01:210309|0016|00): boff=3, want=RQ|01:210309|0016|00, tout=2021-02-15 21:59:59.971725: RE-SENT (4/5) 21:59:59.600 || HGI:140073 | CTL:210309 | RQ | rf_check | 00FF || {'zone_idx': '00'} 22:00:01.202 PktProtocolQos.send_data(RQ|01:210309|0016|00): boff=3, want=RQ|01:210309|0016|00, tout=2021-02-15 22:00:01.601779: RE-SENT (5/5)

[ghoti57]

@FrankvdAa The needle hole next to GDO0 looks like it's going to test the pad on the daughterboard. Did you test the connection to the pad actually on the CC1101 module

[ghoti57]

I don't think we need any more traces, they're cluttering the conversation. It's fairly obvious that TX is not working for some reason.

[FrankvdAa]

@FrankvdAa The needle hole next to GDO0 looks like it's going to test the pad on the daughterboard. Did you test the connection to the pad actually on the CC1101 module

Both, just also did a re-test with the pad on the CC1101 and D3 on the Nano and it's fine.

[FrankvdAa]

Contacted my colleague; unfortunately he doesn't have a logic analyzer.

Might a scope help shedding some light here?

[domb80]

Afraid I am not very technical with hardware, but if it helps I can send the device to a UK address if anyone wants to investigate further. Anyway amazing work guys.

[ghoti57]

@FrankvdAa The needle hole next to GDO0 looks like it's going to test the pad on the daughterboard. Did you test the connection to the pad actually on the CC1101 module

Both, just also did a re-test with the pad on the CC1101 and D3 on the Nano and it's fine.

Fine, Just wanted to be sure. Any chance of testing between D3 and pin on cc1101 chip to be certain.

[ghoti57]

Scope is harder because it probably has fewer channels and it's hard to get a long capture. Channels in priority order are GDO0, GDO2, CSN. use repeated trigger on CSN. Disable trigger immediately after manual TX.

[FrankvdAa]

@FrankvdAa The needle hole next to GDO0 looks like it's going to test the pad on the daughterboard. Did you test the connection to the pad actually on the CC1101 module

Both, just also did a re-test with the pad on the CC1101 and D3 on the Nano and it's fine.

Fine, Just wanted to be sure. Any chance of testing between D3 and pin on cc1101 chip to be certain.

Seems to be fine too, it's the lowest pin on the right side of the chip, correct?

[ghoti57]

Scope is harder because it probably has fewer channels and it's hard to get a long capture. Channels in priority order are GDO0, GDO2, CSN. use repeated trigger on CSN. Disable trigger immediately after manual TX.

You should see CSN activity before and after TX packet on GDO0. Make sure both CSN sections are visible on single capture.

[FrankvdAa]

Scope is harder because it probably has fewer channels and it's hard to get a long capture. Channels in priority order are GDO0, GDO2, CSN. use repeated trigger on CSN. Disable trigger immediately after manual TX.

You should see CSN activity before and after TX packet on GDO0. Make sure both CSN sections are visible on single capture.

I'll see what I can arrange! ;-)

[ghoti57]

Normal trace behaviour is 8n1 UART trace on GDO2 followed by SPI burst for RX. For TX, short SPI burst, 8N1 UART data on GDO0 followed by second SPI burst

[FrankvdAa]

Just found this post: https://forum.fhem.de/index.php?topic=110966.0

Maybe not exactly our problem, but also a case where RX is working and TX is not. There they are saying that the CC1101 might be losing its frequency setting.

[iMiMx]

Has anyone touched base with the seller, in case there are wider problems? Is the current thinking, that this is a hardware related problem, probably not resolvable by the average person?

(My hardware knowledge in this regard is pretty much non-existent)

[FrankvdAa]

Has anyone touched base with the seller, in case there are wider problems? Is the current thinking, that this is a hardware related problem, probably not resolvable by the average person?

(My hardware knowledge in this regard is pretty much non-existent)

Yes, I have send the seller a message through eBay. Awaiting his reply.

[iMiMx]

Did you hear back from the seller? I haven't yet, but then I don't speak German either :)

Was bored, so tried reflashing my nanoCUL a few times, using the the older method using the Arduino Nano board, then with the evofw3 custom board.

The 'old bootloader' didn't work for me on either giving the below error:

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00

I had to choose the Standard bootloader option - but both board options - not sure if this means it's a difference, or perhaps out of date instructions for the latest version of evofw3.

Tempted to just buy another from another seller, not exactly expensive.

[FrankvdAa]

No response from the eBay seller yet.

About the bootloader; I don't think it'll make any difference, it just depends on the hardware you have which option to select. Mine doesn't work with 'normal' bootloader.

Would be nice if we could get the nanoCUL to work properly, but agree with your point about buying one from another seller.

Tomorrow I'll speak to my colleague to see if it is possible to debug with scope.

[ghoti57]

old or new bootloader depends on what's been programmed in the device when you get it. The only difference is the baudrate that gets used.

One will work and the other won't.

Please stick to the evofw3 board definitions

[ghoti57]

In terms of buying a new board see this link. https://www.automatedhome.co.uk/vbulletin/showthread.php?6366-Introducing-the-HGI80-alternative-the-latest-DIY-kid-on-the-block

They won't be long

[ghoti57]

If you're bored...

Try loading the calibrate branch. In serial monitor make sure line ending is CR & NL

Enter command !FT

This will start an autotune process. It takes 40-50 minutes. It reports lots of errors (expected) When it's finished it'll just carry on as normal reporting messages.

Do NOT close Serial monitor or reset the nano. enter the command !F

This will print the FREQ value that the cc1101 is now using.

Try sending a RQ message to the controller and see if you get a response now. Let me know the result and the FREQ value

[ghoti57]

If there is a frequency related problem this may show us something

[ghoti57]

Interesting that you bought the devices from the same supplier but they're using different bootloaders

[FrankvdAa]

If you're bored...

Try loading the calibrate branch.

Just loaded the calibrate (v0.6.12) firmware and started the autotune process. Will get back with the results ;-)