If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
If you have an OT Bridge then unfortunately you cannot switch from the HGI80 just yet. For some reason the HGI80 clones don't like the OT Bridge messages. It is of course hardly important because Domoticz doesn't decode the OT messages anyway.
Also the HGI80 receives a lot more than the clones. The clones are about 98% good.
It's either that or we haven't bottomed out the radio parameters out completely, as they are used in the HGI80.
Specifically with my firmware, I suspect it's most likely to do with the way I'm using software bit-banging to decode the incoming signal causing an occasional loss of synchronisation and therefore garbled messages. My next task for my firmware is to see if I can get it to use more of the radio chip's hardware packet handling features to try and eliminate this as a cause. Unfortunately, without some very expensive lab equipment (i.e. a signal analyser, etc.) there's not much I can nail down as a definite cause, and I'm working with guesswork.
Sadly, I'm seriously lacking in time at the moment. My current contract is coming to an end soon which could either free up some time in between interviews, or cause me to spend 8 hours a day endlessly on the telephone, or cause me to take up permanent work. In short... no promises!
But I have OpenTherm now, so I do need to make an effort to get the firmware reading OT messages correctly. Then we need to figure out what they mean and build that into Domoticz.
Specifically with my firmware, I suspect it's most likely to do with the way I'm using software bit-banging to decode the incoming signal causing an occasional loss of synchronisation and therefore garbled messages. My next task for my firmware is to see if I can get it to use more of the radio chip's hardware packet handling features to try and eliminate this as a cause. Unfortunately, without some very expensive lab equipment (i.e. a signal analyser, etc.) there's not much I can nail down as a definite cause, and I'm working with guesswork.
Impressive work so far. After reading a lot here (and a lot of code as well I believe you have taken the most promising and flexible approach to talking to the evohome network. Did you get around to trying to delegate some packet handling? I've ordered a few CC1101s to hook up to a faster microcontroller; maybe that'll help as well (or at least confirm your hypothesis).
It will probably take me a while to port your work, so any progress (or discoveries not discussed here yet) is welcome!
After reading a lot here (and a lot of code as well I believe you have taken the most promising and flexible approach to talking to the evohome network. Did you get around to trying to delegate some packet handling? I've ordered a few CC1101s to hook up to a faster microcontroller; maybe that'll help as well (or at least confirm your hypothesis).
It will probably take me a while to port your work, so any progress (or discoveries not discussed here yet) is welcome!
No real progress lately, I'm afraid.
When you talk about porting it, what are you thinking of porting to?
It comes with the nanoCUL build of culfw installed but that doesn't support the evoHOME option (it needs 2 UARTs)
So I downloaded the current master branch of @dty's evofw2.
Added a new HW include file to define the i/o + baudrate (76800) and updated config.h.
Made a few mods to Makefile (MCU=atmega328p, F_CPU=16000000 and some AVRDUDE parameters).
Hooked it up to putty on windows and bingo, could see all the messages being sent by Wifi, HR92s and BDR91. RX definitely working with occasional errors (mainly BAD STOP BIT).
I want to test TX but not sure of command format - can anybody provide me with a simple command that I can use to prod something in the system?
Once I know that's working I'll clone the git and do the edit's properly. (@dty we may need to discuss how best to handle the Makefile)
Excellent news! Send me a PM with your email and I’ll add you to a Slack chat room where a few of us discuss this stuff (although it’s been pretty quiet of late).
If you hook it up to Domoticz, it can write in the correct format. I think from memory that it’s broadly the same as the receive format but with the first field (RSSI) removed. Having said that, I’m not convinced sending is working at the moment.
If you hook it up to Domoticz, it can write in the correct format
I'm currently running Domoticz on a Synology and I have all the USB ports in use :-( Planning to switch it to a pi I've got lying around.
Meanwhile I want to try to prove the port in as simple an environment as possible.
I'm just looking for the format of a simple command that will provoke a response.
I haven’t looked at the code for a year or so, so I can’t remember the format, etc. Best bet is probably to look at the Domoticz code for examples of messages it sends.
If you’ve got a reasonably up-to-date Domoticz, you can use the Evohome TCP driver to connect Domoticz running on your Synology to “socat” or “ser2net” running on an RPi with the radio connected. That’s what I do. I developed the Domoticz Evohome TCP hardware specifically so I could site my radio in a more favourable position for reaching the whole house!
I think the problem was that nothing else was prepared to do RX.
Scanning my RX log I came across an interesting feature around 4 am every day.
All my HR92s start transmitting RQs like
--- RQ --- 04:012221 01:140959 --:------ 313F 001 00
to which the controller replies
--- RP --- 01:140959 04:012221 --:------ 313F 009 00FC070024170107E2
This a detailed time stamp
07 = 7 secs
00 = 0 mins
24 = 001 01000 = day of week 2 + 4 hrs
17 = day 17
01 = mon 1
07E2 = 2018
The day of week appears to be monday=0
So this morning I tried this
RQ --- 18:370 01:140959 --:------ 313F 001 00
and promptly received this
--- RP --- 01:140959 18:000370 --:------ 313F 009 00FC2135861A0107E2
( This looks like it could be a nice 'ping' of the controller. )
So it looks like this package could be a good choice for anyone who doesn't feel competent with a soldering iron
It's less than half the price of the cheapest HGI80 I could find.
Apart from i/o configuration it seems that @dty's evofw2 just works.
Also because it's 16 MHz it appears to run successfully at 115200 baud (I tried it successfully at 250000)
I suspect my early failures were down to trying to get simple data from the HR92s while they were asleep
I got the clue from this post over on domoticaforum
My system seems to be running on a 220 second period.
Does anybody know how long the HR92s are awake for?
Could this be part of the reason why some people report problems with sending messages from Domoticz?
Does Domoticz do anything to try to schedule any commands it sends out or does it only ever try to talk to the Controller (which I assume is always awake)
Unfortunately none of the home brewed solutions are able to read the Opentherm messages yet. Also there are messages that the HGI80 picks up that the others don't. But I agree as a cheaper alternative they are great.
Comment