Hi Robert,
We are talking about emonpiCM, correct ?
The emonhub sends commands today in the reverse polish format, notably using the ‘s’ postfix. This can easily be validated by looking about at the python code.
Currently you send a MQTT msg to emonhub/tx//values/msg/ with the BYTES you want to transmit, encoded specifically according to the emonhub TX definition.
Your change breaks this as it is no longer accepted, nor does it accept a decimal string which is converted into bytes for onward transmission.
I refer you to lines 235 - 256 of EmonHubJeeInterfacer.py for TX. In fact looking at the entire file it relies on the current implementation for any commands SENT to the uC.
This breaks inter-operability and will require changes to this code and additionally any existing software that uses it for tx. Not great I’m sure.
But, I think you’ve misunderstood my comment, so please do read it again and look at the current code to see how it works. Your CM code is a great improvement so I think getting it 100% compatible is a worthy endeavour.
However, I came on here to post some other news, which is that I’m finding the RF12b sending RFM69 packets to be buggy and unreliable. The simple idea to change the define in the code and restart / recompile does not work, except in the most simplistic cases.
For example - do this in the standard rfdemo sketch and you’ll find it doesn’t work. Even after manually sorting out the rf12_initialization. In short, the ONLY way I could get it to work is comment out the PRGMEM definition for help1 text. In that case it worked (after some other prodding). However, this is without even calling the help to execute the function to display the help text, so there is a rather nasty memory corruption bug somewhere in the RF12 libs. This took many many hours to bottom out.
I then verified this by trying on my own known code (for controlling rollerblinds), which would not get past a simple f12_initialise (hung) on the same board, and it works perfectly with the old packet mode. Flipping the ```RF12_COMPAT back to zero and no issues.
With the upcoming emonpi2 release, I guess we need to figure out the way forward. I think JCW has been pretty quiet over the years and moved onto other things… embello is pretty quiet and bugs don’t seem to get fixed. In my opinion it’s a dead codebase, and even the the jeenode/jeelib website is now found mostly on the wayback machine. You are now essentially have to maintain the RF69 code.
Given my tests, that conclude for me at least that RF12 doing native RFM69 packets is far from stable and therefore inter-operability not guaranteed, it may be time to look again at lowpowerlab, which is at least developed and supported.
Changing the code for a small handful of devices would not be super difficult and the decision forced to use a different packet format made, we may as well make something that is current.
That’s my 2c on this, but at the very least, this needs some more testing to make it work with current ecosystem of things that may have RF12 onboard (which from OEM is only the emonGLCD, right ?).
I’ve spent a good few hours on this at this point and unless you want to take the decision that sending will not work without changes upstream, I’d step back and re-evaluate.
Again, sorry I’m late to this party.
)