My HGI80 equivalent Domoticz setup without HGI80

[DanD]

@dty

Yes, you might be right about overloading the MCU with interrupts. It doesn't look like this though as it seems to always be the same few devices which suffer the *INCOMPLETEs and I think this seems to point more towards a signal/CC1101 problem. It could be though that these devices send a burst of consecutive messages, causing an overload of interrupts. I'm really not sure yet. The alternative approaches in your firmware should help with troubleshooting.

Yes, we're using the synchronous clock approach. The RFBee has an Atmega168/328 running at 8Mhz (3.3V). There are two different versions of the RFBee in circulation; v1.1 has the 168 with an internal clock that can be tweaked via OSCCAL, v1.2 has the 328 with double the memory, but uses an external clock.

Dan

[dty]

I think I'm having the same conversation with Bruce via email!

I doubt it's the radio parameters. I've found that's all-or-nothing. Once you're getting bits, you're getting bits. Maybe slightly tweaking the centre frequency or something would help? If it's not quite right, but the HR92 transmission are within tolerance and the HR80s are not?

I assume you've looked at/tried my radio parameters? I don't have any HR80s, so I can't comment on whether they're working or not. I don't think (the build I'm using of) Domoticz logs errors when it gets error packets (\x11) from the device, so I don't have good visibility into how reliable my reception is right now. Most devices seem to stay up-to-date, and my Pi sits right next to my Evohome controller, so it should see the same radio strength. But I do occasionally get some devices which don't appear to update for hours at a time, so perhaps I'm dropping messages sometimes and not realising?

[DanD]

@dty

Yes, it does look like it could possibly be that the HR92s and other newer devices are within tolerance of the CC1101 settings, but the older HR80s (and a CM67z controller I'm using in my test set-up) aren't. I've tried isolating my test set-up of a couple of HR80s and a CM67z from my live Evohome system and doing some further testing, tweaking the RF frequency setting, but I don't think this helped. Similarly, I've tried using the CC1101 frequency offset functionality in this set-up to see if it's chasing a different centre frequency, but didn't get any conclusive results. Possibly, the HR80s/CM67z were showing greater drift in their transmission frequency, but it wasn't clear and I still was getting the incompletes. I took a quick look at your radio parameters last night and I think we're using the same ones, but I'll double-check.

The general testing approach that Bruce and I are using is to monitor the messages using our HGI80 and RFBees located in near to each other and then comparing the message streams. My main system is all HR92s, so I get a pretty good match between devices, but still have to do some more detailed testing on this as I was possibly missing my DHW sensor even if I relocated the RFBee to be closer. It's only when I start to add HR80s into the mix I get the message incomplete problems, similar to Bruce's experience, as his system is all HR80s.

Thanks,

Dan

[bruce_miranda]

I think there is something about the radio parameters that makes a difference. The reason I say this is, there is a version of the firmware where a guy changes the frequency offset at every message. Now on it's own that doesn't help very much. But if I amend a few of the radio parameters, suddenly I get an extremely clean output, but am missing many messages altogether.

[dty]

Since this conversation has now spilled out into PM and e-mail (as well as this thread), I've created a Slack group to try and re-centralise it Anybody who wants to join can PM me.

[Shutty]

@shutty

As Bruce has said it's all work in progress at the moment, but if you're happy to dive in here's some info which should get you started:

RFBee firmware: I suggest trying the master branch from my Github area, but you may have to try altering the baud rate to 74880 or 250000 to get sending to work OK. I'm sure I've got it to work on the default 115200, but I tested it again yesterday and had to change the baud rate to get sending to work. I've paused on further work on the firmware at the moment until some more hardware turns up, as I wasn't able to get to the bottom of some problems with *INCOMPLETE errors in some of the messages from HR80s. I hope to be able to do some more troubleshooting on these messages with my new toys in a few weeks.

Dan

Dan, you are using some non standard baud rates here, something i have not tweaked before.. Are you updating the available values in registry for the FTDI. ? thanks

[bruce_miranda]

The ftdi driver baud rates are only defaults. They can be overridden by the client. So you don't need to amend anything. Just make sure your serial client is set to the same baud as the source arduino serial open.

[DanD]

@shutty

All I do is set the baud rate in my RFBee firmware (Serial.begin(XXXXX)) and the set the same baud rate is whatever serial client I'm using in Windows (mainly PuTTy or the Arduino serial monitor, but it only has a limited selection of baud rates). I'm really not sure about the exact benefits of going either above versus below 115200, I just know that using 115200 causes problems. A few of us are actively working on tweaking the firmware and hopefully I'll fully understand exactly what I'm doing at some point.

Obviously if you're messing with the baud rate you'll need to change it in Evohome.cpp in Domoticz too and recompile.

Dan

[Shutty]

@shutty

All I do is set the baud rate in my RFBee firmware (Serial.begin(XXXXX)) and the set the same baud rate is whatever serial client I'm using in Windows (mainly PuTTy or the Arduino serial monitor, but it only has a limited selection of baud rates). I'm really not sure about the exact benefits of going either above versus below 115200, I just know that using 115200 causes problems. A few of us are actively working on tweaking the firmware and hopefully I'll fully understand exactly what I'm doing at some point.

Obviously if you're messing with the baud rate you'll need to change it in Evohome.cpp in Domoticz too and recompile.

Dan

woohoo working... did not realize the client was overriding the com port.(basic lack of knowledge there after 20yrs in IT... Doh...) ....... although it appeared ok at 115200, receiving was fine but not sending. moving the baud down has fixed it , as you advised earlier in the thread. Currently using your python script Dan with your version of firmware... seeing the odd unknown header but my hr92 is syncd... interesting to follow the comparison testing between the hgi80 and rfbee, trying to generate identical output, but I am afraid I can't add any value to that discussion, its quite a specialized subject I see.

[DanD]

Excellent! It's great to hear that sending is working for you too. With regards to comparing received messages between the RFBee & HGI80, I'm just capturing the output in a couple of PuTTy sessions. I've set the history to 1000 and then I'm just pasting them into Excel for manipulation. It's tricky to differentiate between potential firmware problems & reception issues, but we're working on it. Please share any observations from comparing the messages from your two devices.

Dan