HTTP requests and/or publish to MQTT from rules (Feature Request)

[archi]

As the title states, these could be useful to rely less on e.g. Node-Red for some controls.

Background: I have a buffer. Now when emulating the optional PCB to deliver Buffer Temp, Room Temperature and Z1 Water Temp, the HP tells Heishamon to power on the Z1 circulation pump, but does not turn on the (actual) circulation pump connected to its own PCB. Hence it believes the radiators are getting hot water, while the water is not moving at all.
The obvious solution now is to use Node-Red to listen to panasonic_heat_pump/optional/Z1_Water_Pump and turn on/off a WiFi relay.
Now this isn't really an optimal solution, since it means if Node-Red is down (which runs as an AddOn in my Home Assistant VM), the circulation pump is not properly controlled. My mosquitto however runs on the actual machine and continues to run over any Home Assistant updates/crashes etc. Moreover, the WiFi is on PoE on a big UPS, so even if the physical server is down for updates, the WiFi will continue to run.

I would prefer to write a rule that reacts on the Z1_Water_Pump event and either does a HTTP call to the WiFi relay itself (preferred), or at least publish to the relays MQTT topic.
Is this a feature you think makes sense?

Alternatively, I'd be happy to abuse some of the existing IO pins of the Heishamon PCB (I have a recent one from TheHogNL) and control one of these a 5V relay PCBs directly from Heishamon. (I suppose if someone wants to discuss this, it's better to open a separate issue and ping me there).

P.S.: I took a quick glance at the source and would be happy to contribute. But there are no comments, which makes the code hard to grok. I think I have a basic idea how to add these functions. Obviously dynamically manipulating strings would be a lot of work, but just passing constants should be enough [and that's what I had in mind anyway].

E.g. mqtt_pub("my/awesome/To pic", "on") or http_get("http://1.2.3.4/do?action=on") with purely constant strings should be doable; as far as I can tell this requires:

• Adding quoted string parsing to the lexer (existing string parsing would trip on URLs and topics with whitespaces)
• If necessary due to URL/topic sizes: a table for string constants
• add a function callback for http_get and/or mqtt_pub

[MiG-41]

I also permanently requesting for such feature ( possibity to use GPIO ,as a state ,at least for OptionalPCB controls).
would be implemented either directly , or by rules ( i asked @CurlyMoo as well as @IgorYbema ).
From one side idea is good , but for me not possible to implement by my own :)

[archi]

Good idea to ping CurlyMoo! I found https://github.com/CurlyMoo/rules, which I guess to be original source of the rules engine? Now the question is: Where to implement my feature request and direct a PR?

[geduxas]

As heishamon is already using web component, it's possible to open external url. Truly if it's not encrypted.

[geduxas]

I think it also could be implemented in rules..

[CurlyMoo]

At the moment string handling inside the rule parser is a major change so the only option would be the GPIO calling from the parser. However, that requires the help from @IgorYbema

[IgorYbema]

GPIO control is indeed something which I already planned some time ago but never got further into this. all 4 GPIO's left do have there issue's. We have the TX/RX (gpio1 and gpio3) which are not clean during boot so it flaps the relays (is that bad?) during boot. Also these are used for opentherm on the opentherm boards so can't be used then.
We have gpio2 for the debug and blue led. User could choose to disable that and use gpio2 for relay.
And we have gpio15 which can only be used as output also.

I am happy to generate a new test firmware with some controls for gpio -> relay.

And I understand you can't change the wifi relay mqtt topic it listens on? Because if it can, it just can listen to the topic from heishamon.

[MiG-41]

@IgorYbema , i don't know if i understand your question corectly , but idea is to drive devices like zone pumps diectly from heishamon ( with act like optional PCB) , and not thru other devices like servers with mqtt ,with can fail , but HP have to run anyway :)

EDIT: GPIO outputs ,like Zone pumps , but also GPIO inputs like zone thermostats :)

EDIT2: GPIO12 and GPIO14 could be also involved , since S0 feature is something ,with not everybody use... Ideal for Inputs ( signal treat as Thermostat state instead counting) . Also in systems like Tasmota it is possible to asssign particular gpio several functions ...

[IgorYbema]

Yes that is what I mean also. But he also asked to control over mqtt and that is possible but requires his wifi relay to listen to the heishamon topic.

GPIO input is harder to do on these 4 GPIOs due to limits during boot. But for the GPIO12 and 14 from S0 could be possible indeed.

[IgorYbema]

just the price indeed :)

[archi]

At the moment string handling inside the rule parser is a major change so the only option would be the GPIO calling from the parser. However, that requires the help from @IgorYbema

Yeah, I spend some time looking at the quoted strings. Not trivial adding this to the existing code :( Of course working on embedded makes things a bit more complicated... I gave up when I could not figure out where to put the resulting string table.

re GPIOs: I didn't check the schematics for my Opentherm-enabled PCB, but cannibalizing the S0 GPIOs is something I'd like; especially if that means being able to use the existing screw terminals ;-)

Alternatively, there seem to be 1 wire ICs to control relays (DS2413), but they're 3.50 Euro at digikey and there are no dirt-cheap 1 or 2 relay PCBs available with them.

re listening to mqtt topic: You're right, that's something I didn't think of! Seems a bit more involved on tasmota, but ESPhome can do it.

Because it was asked: Emulating the optional PCB is a nice way to send a room temperature to the HP. That's not possible with the original PCB. However, from what I gather, I should probably look into the Node Red controller instead. My installer can then just put in the optional PCB + sensors.

[IgorYbema]

The S0 can be used for input only due to the schmitt trigger ic in between (to filter s0 input noise).
On the opentherm enabled board the only gpio's left are the gpio12 and gpio2 for output. Let me look into this for you.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[archi]

This is a feature request. Can't you label it as such and have the bot exclude feature requests? Or was the plan to also close feature request for which people don't nudge?

You could also add "help wanted" labels if you're open to PRs (I'm a label fetishist, sorry 😆)

If you think adding this feature makes

• no sense anymore
• or is not possible
• or simply takes more time than you want to spent on this (awesome and free!) project [maintaining the code, even if it came from a PR, also takes time]
• Or really "whatever, you're the boss around here":

You can of course close this as "not planned/won't fix" at your own discretion ;-)

On topic:

Ah, for the record: I personally could still use this to remove points of failure. Especially http.

What is the status over on the rules engine? I'm on mobile and real life demands attention; so I can't check if there has been any work that might simplify this.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[archi]

Not stale, just patiently waiting.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[archi]

Can this be closed as "will not be implemented"? @IgorYbemaAm 21.12.2024 03:31 schrieb "github-actions[bot]" ***@***.***>: This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[archi]

Waiting for @Egyras

[geduxas]

i think all feature request should be moved to discusion's and discused there..

[Egyras]

Maybe better place could be in discusions.