Use serial port the same way as MQTT

[matsekberg]

Is your feature request related to a problem? Please describe.
Im using OpenHasp in an environment where wifi is not stable. A better solution would be to use the serial port.

Describe the solution you'd like
First I would like an option to kill all the debug messages on the serial port.
The I would like to be able to send commands and receive status over the serial port, as if it where MQTT.
The same commands/topics/data etc could be used.

Describe alternatives you've considered
Due to the debugging noice the serial port is not a great choice today.

Additional context
These messages is really annoying if using serial as a wired MQTT:

Prompt > [14:18:18.931][34804/46800 25][33404/33976 2] MQTT RCV: = p2b13.text=0
Prompt > [14:18:18.940][34804/46800 25][33404/33976 2] MSGR: p2b13.text=0
Prompt > [14:18:18.959][38900/47152 17][33864/34148 1] MQTT RCV: = p2b12.text=0
Prompt > [14:18:18.968][38900/47152 17][33864/34148 1] MSGR: p2b12.text=0
Prompt > [14:18:18.980][38900/47152 17][33864/34148 1] MQTT RCV: = p2b21.text=0
Prompt > [14:18:18.989][38900/47152 17][33864/34148 1] MSGR: p2b21.text=0

[fvanroie]

Hmmm, can you specify the use-case? openHASP was conceived as an MQTT client device.
Serial could be possible, but what device would you be talking to? Is that plain text or json payloads?

I think Serial1 should be reserved for debugging, but can be disabled.
Maybe Serial2 could be used for this...

Receiving commands can be done using custom code. The status updates will be trickier...

[fvanroie]

Did you manage to resolve this issue or is this still pending?

[matsekberg]

The specific use case is when I’m using the displays in my RV without WiFi. But rather serial connection to the controller.

[fvanroie]

I think this is more of an RV integration issue, than Home Automation...

Without knowing anything about these systems it's going to be talking to, you'll have to piece something together that works for you... You can check out the custom code section to maybe add this functionality.

[macbef]

I'm with @matsekberg here. From the documentation I thought that the use of commands would be the same, no matter which interface you use (MQTT, Serial, Telnet). But I found out that feeding commands to the serial port has to be done really slowly (I have to wait 2ms after each character to be sure to have a stable connection.
It would be so cool to have a command like "debug off" and switch to a transparent serial communication.
Basically most functions already are there. You can send jsonl commands via serial. (Very slow though)
The only thing I couldn't find out was how to get the status of objects. Sending p1b1.val without parameter doesn't trigger a reply.
p1b1.val=1 echoes the changed value with a debug message. It would be great to have this kind of response:

Command: "p1b1.val"
Reply: "p1b1.val=15"

As for the use case: I have developed a modular system with machine automation on my mind. As a HMI I'd like to use a cheap ESP32-8048S070 display, connected through UART.
The prototypes are working great. Only the feedback from the display is missing.

Any help would be appreciated. If needed I could supply free hardware samples :)

[fvanroie]

Like I stated above, the serial debug is meant as a debug tool. You can interact with it that way, but no effort was made to use it as an API.

Because this is a custom application of the firmware, I would repeat that a separate Serail2 connection should be implemented using the Custom Code interface.

[macbef]

Yeah, you are right. I'll look into the custom code idea.
But just for my understanding, maybe I missed that:

Is there no command that outputs the state of an object?
I see that there is a command for GPIOs (input[x] and output[x]), returning input4 => {"state":"on"}
But there is nothing similar for the objects?

The same applies to commands like moodlight:
The docs say that:
Calling the moodlight command without parameters (or sending an empty payload to the hasp//command/moodlight topic) returns the current state...

But when I send the command "moodlight" via serial or telnet I get no "status" reply.

[fvanroie]

Weird... when I issue the moodlight command without a payload, the response is the current state:

[16:28:32.767][32756/35548  7][47416/48608  3][loopTask  3148] MSGR: moodlight
[16:28:32.791][30708/32368  5][47416/48608  3][loopTask  3148] MQTT PUB: moodlight => {"state":"off","brightness":255,"color":"#000000","r":0,"g":0,"b":0}

[macbef]

What do you get when you issue ''p1b1.val''?
Maybe I don't get the MQTT PUB debug info because I'm not connected to an MQTT broker?

[macbef]

By the way, I evil-fixed the problem by adding this to hasp_dispatch.cpp:

void dispatch_state_subtopic(const char* subtopic, const char* payload)
{
    char sendStr[64];
    snprintf_P(sendStr, sizeof(sendStr), "%s => %s", subtopic, payload);
    HASP_SERIAL.println(sendStr);  // super-evil echo of the sendStr (just for my implementation)
    LOG_INFO(TAG_MSGR, sendStr);  // added log-info (this might be useful for everybody)

#if HASP_USE_MQTT == 0 && HASP_USE_TASMOTA_CLIENT == 0
    LOG_TRACE(TAG_MSGR, F("%s => %s"), subtopic, payload);
#else

[fvanroie]

Yes indeed, I have MQTT enabled, since that 's the normal operational mode for openHASP.

The not evil code would be to add a hook into the custom code, so a callback can be used to send the data to a Serail port.

[fvanroie]

I could add a void custom_state_subtopic(const char* subtopic, const char* payload) callback that gets called by the firmware when HASP_USE_CUSTOM is enabled. What do you think?

[macbef]

That sounds good! Please do this if it's not too much trouble.

[fvanroie]

done!

[FreeBear-nc]

As for the use case: I have developed a modular system with machine automation on my mind. As a HMI I'd like to use a cheap ESP32-8048S070 display, connected through UART. The prototypes are working great.

Machine automation (PLC, motion control, etc) is a pet interest of mine. Would like to know more about your little project. As GH doesn't allow for PMs, feel free to open a discussion in one of my repositories (saves clogging up this one).

[macbef]

Thanks for the update, @fvanroie !!

[macbef]

As for the use case: I have developed a modular system with machine automation on my mind. As a HMI I'd like to use a cheap ESP32-8048S070 display, connected through UART. The prototypes are working great.

Machine automation (PLC, motion control, etc) is a pet interest of mine. Would like to know more about your little project. As GH doesn't allow for PMs, feel free to open a discussion in one of my repositories (saves clogging up this one).

I've started a new repo with some pictures. I'll post more information once I find the time. Please start a discussion here:

https://github.com/macbef/OMP-Open-Modular-PLC

[matsekberg]

Yeah, you are right. I'll look into the custom code idea. But just for my understanding, maybe I missed that:

Is there no command that outputs the state of an object? I see that there is a command for GPIOs (input[x] and output[x]), returning input4 => {"state":"on"} But there is nothing similar for the objects?

The same applies to commands like moodlight: The docs say that: Calling the moodlight command without parameters (or sending an empty payload to the hasp//command/moodlight topic) returns the current state...

But when I send the command "moodlight" via serial or telnet I get no "status" reply.

Have you made any progress in using serial rather than MQTT?
Have you looked at HaspMota as an alternative?

[fvanroie]

I think this can be closed now?