NodeRed MQTT for Tasmota; which parts are topic, payload etc?

[roguestreak]

I'm having trouble researching where exactly the line is between a topic and a payload, and how I need to work it to individually address a string of WS2812 LEDs.  The goal is to visually display my solar generation and power consumption simply on a 16px ring, with each "pixel" representing 1/3 kW (ie. display up to 5.33kW)

From my understanding of the Commands list, for each LED (aka. pixel) I need to publish an MQTT msg as such ("sonoff_leds" being the device):

sonoff_leds/cmnd/Led1 00FF00

sonoff_leds/cmnd/Led2 00FFFF

etc?  Am I reading that correctly?  I can't find any examples of people addressing each LED indiviually with a Tasmota'd device.

So, my next confusion is whether the "Led1", Led2" etc are part of the topic, or part of the payload?  Are they commands rather than topics?  Can anyone familiar with NodeRed advise on how to construct such a msg, or preferrably use the node.send() method as I need to send out 16 of these messages using a for loop to populate the LED number and colour content?

I believe I've figured out at least the pseudocode for the population system, but am having issues figuring out exactly how to spit out those variables to the string (ring).  I'll share it here when I get it operational, as I reckon it would be a cool simple realtime display of power generation/consumption.

Thanks for any advice

Lee

[Mike Roberts]

Try cmnd/sonoff_leds/Led1 00FF00 etc

Mike

[roguestreak]

Hi Mike
OK so I've got the cmnd in the wrong part of the topic... but the main query is where the topic ends and where the payload begins?  Is "Led1" part of the topic, or as a command is it part of the payload?
Is it something like msg.topic = "cmnd/sonoff_leds/", msg.payload = "Led1 00FF00"?
Or if Led1 is part of the topic, how can I use node.send() to create a different topic AND payload per item in the aray?
Thanks
Lee

On Thursday, February 1, 2018 at 7:38:53 PM UTC+10, Mike Roberts wrote:

Try cmnd/sonoff_leds/Led1 00FF00 etc

[Bryan Mayland]

Led1 is part of the topic, as in the topic is cmnd/sonoff_leds/Led1 and the message is 00FF00. You can't send to multiple topics at the same time, you can only publish to a single topic per message. However, tasmota is just about the greatest because it has a special topic cmnd/sonoff_leds/Backlog which allows you to send up to 16 commands at once with a message like "Led1 00FF00; Led2 FF0000; Led3 0000FF". Be careful that your whole message fits inside a single MQTT buffer though, I'm unsure of the buffer size in Sonoff-Tasmota.

[roguestreak]

Ahh, thanks Bryan, sounds like that should fit the bill nicely; in fact seems almost custom made for these WS2812 rings!
I think 16 of these commands would equal about 180 bytes, but I haven't tracked down a specified figure on how big the tasmota buffer is; there's reference to a larger buffer on the sonoff-ds18x20.bin, but can't find anything yet that says what either version's size is.
Lee

[Bryan Mayland]

I just looked it up because I was curious too. Looks like MQTT_MAX_PACKET_SIZE is 512 which needs to include the topic and the payload and a handful of bytes that wrap it. So as long as your topic isn't too long, then you should be good to go!

[roguestreak]

Thanks Bryan, good to have that info handy.  I'd say as an absolute max it should come in at under half that size, using something like this as a guestimator:

http://bytesizematters.com/

L

[roguestreak]

I've just been messing around using the direct web console, and strangely it refuses to work if I put in all 16 Leds; I can do any 15 fine (including Led16), but as soon as I add the last one to the backlog it just says "backlog appended" without actually deploying anything.
[EDIT] Just tried with a direct mosquitto_pub and it does the same thing, reduce the output to 15 and it works!  I guess we've found the limit, might have to break it into two arrays, it works if you publish say Backlog Led1 - Led8 and then backlog Led9 - Led16, guess I'll have to work on the logic of how to do that!

[roguestreak]

[EDIT 2] or maybe it's the limit of the Backlog function actually being less than 16 commands, not equal 16?

[roguestreak]

Well I've decided just work around the missing 16th and drop it, giving me 15 pixels to work with or 5kW at 0.33kW per pixel.  I've just made my first basic node-red flow and it's working!  Unfortunately it's a miserable rainy day so I'm currently hovering between one and two pixels production rather than the maxed-out 15pixels I should often see in summer!

Next step is to start getting live data on our consumption, and overlay that it different colours for the main consumers;  electric hot water, air conditioning, pool pump, oven etc., giving an at-a-glance indicator of self-consumption vs grid consumption.

Here's my initial Function from node red, it feeds from a Channel in OpenHAB (solar kW as a float, from the inverter's logging data scraped from their monitoring site), and outputs to MQTT.  "sonoff_pool" is just a tasmota'd Sonoff Basic I'm using as a test environment, as the name might suggest it'll later reside at the pool pump and be activated for a pre-determined period when there's power free, depending on which other loads are prioritised.

var currentSolar = parseFloat(msg.payload);
var msgNew={};
msgNew.topic = 'cmnd/sonoff_pool/Backlog';
msgNew.payload='';

var solarUpscaled = currentSolar * 30; //eg. 11.4
var solarMod = solarUpscaled % 10; //eg. 4
var solarNonMod = solarUpscaled - solarMod; //eg. 110
var solarPixels = solarNonMod / 10; //eg. 11

//msgNew.payload = solarUpscaled;

var pixelArr = new Array("null")
for(i=1; i<16; i++)
{
    pixelArr[i] = "000000;"; //pre-fill blank
    if(i <= solarPixels)
    {
        pixelArr[i] = "004400;"; //fill green, free solar
    }
    msgNew.payload += "Led"+i+" "+pixelArr[i];
}

return msgNew;

[Bryan Mayland]

I love it! That's some cool stuff, I have a soft spot for graphs of all kinds-- bar indicators included. I just looked at the code and you're right, if you add 16 things to the backlog there's a bug/design issue that causes the index to roll over back to the first index and then it thinks there is nothing in the backlog any more. Unfortunately, the backlog buffer is circular so there's no way to prevent this other than waiting at least 0.2 seconds for at least one item to be removed from the backlog to hold that 16th item without wrapping the index.