Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use serial port the same way as MQTT #611

Open
matsekberg opened this issue Jan 14, 2024 · 19 comments
Open

Use serial port the same way as MQTT #611

matsekberg opened this issue Jan 14, 2024 · 19 comments
Assignees
Labels
done The underlying issue has been fixed enhancement New feature or request waiting feedback Feedback is required before the issue can be worked upon further

Comments

@matsekberg
Copy link

matsekberg commented Jan 14, 2024

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

@matsekberg matsekberg added the enhancement New feature or request label Jan 14, 2024
@fvanroie
Copy link
Collaborator

fvanroie commented Feb 8, 2024

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 fvanroie added the waiting feedback Feedback is required before the issue can be worked upon further label Feb 23, 2024
@fvanroie
Copy link
Collaborator

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

@matsekberg
Copy link
Author

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

@fvanroie
Copy link
Collaborator

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
Copy link

macbef commented Mar 8, 2024

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.
image

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

@fvanroie
Copy link
Collaborator

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
Copy link

macbef commented Mar 11, 2024

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
Copy link
Collaborator

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
Copy link

macbef commented Mar 14, 2024

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
Copy link

macbef commented Mar 14, 2024

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
Copy link
Collaborator

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
Copy link
Collaborator

fvanroie commented Apr 7, 2024

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
Copy link

macbef commented Apr 9, 2024

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

fvanroie pushed a commit that referenced this issue May 24, 2024
@fvanroie
Copy link
Collaborator

done!

@fvanroie fvanroie added the done The underlying issue has been fixed label May 24, 2024
@fvanroie fvanroie self-assigned this May 24, 2024
@FreeBear-nc
Copy link
Contributor

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
Copy link

macbef commented May 27, 2024

Thanks for the update, @fvanroie !!

@macbef
Copy link

macbef commented May 27, 2024

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

marcoose pushed a commit to marcoose/openHASP that referenced this issue Jul 7, 2024
@matsekberg
Copy link
Author

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
Copy link
Collaborator

I think this can be closed now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
done The underlying issue has been fixed enhancement New feature or request waiting feedback Feedback is required before the issue can be worked upon further
Projects
None yet
Development

No branches or pull requests

4 participants