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

[P013_HCSR04] Add COMBINED mode #3157

Closed

Conversation

clumsy-stefan
Copy link
Contributor

Add a "COMBINED" mode to HCSR04 plugin to be able to use the switch feature together with periodic distance metering. Should be 100% backwards compatible.

Add a "COMBINED" mode to HCSR04 plugin to be able to use the switch feature together with periodic distance metering. Should be 100% backwards compatible.
event->sensorType = SENSOR_TYPE_SWITCH;
if (operatingMode == OPMODE_STATE) {
UserVar[event->BaseVarIndex] = state;
event->sensorType = SENSOR_TYPE_SWITCH;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+ValueCount

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

??

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@uzi18 Can you explain what you meant with your comment?
I also don't really see what you're missing here.

@clumsy-stefan
Copy link
Contributor Author

@TD-er this PR runs for some weeks now stable at my site as well with "traditional" distance meters as in combined mode. So it would be great if it could be merged into mega, if there are no objections….

cheers.

@TD-er
Copy link
Member

TD-er commented Jul 29, 2020

I can only think of a possible issue when it is used to send data to specific controllers (e.g. Domoticz) or shared via p2p to another node running the 'older' version of this plugin.

So I guess that may be the warning @uzi18 tried to make here, that changing the number of output values may lead to these issues I mention here now.

@clumsy-stefan
Copy link
Contributor Author

hmm… but the number of output values only changes in COMBINED mode, in the (old) switch or distance mode the output count is still the same…

@TD-er
Copy link
Member

TD-er commented Jul 29, 2020

Nope, this is what is set as the default: Device[deviceCount].ValueCount = 2;

@clumsy-stefan
Copy link
Contributor Author

could that be changed at runtime?

@TD-er
Copy link
Member

TD-er commented Jul 29, 2020

Well... that's what I do for the sysinfo, dummy and SenseAir plugin.
But it also has some drawbacks.

For example for the Dummy plugin, if you have multiple instances of that plugin, all tasks with that plugin will be set to the.... last changed one :(

@clumsy-stefan
Copy link
Contributor Author

Hmm… Any chance this is beeing integrated? If not, what should be adapted?

@TD-er
Copy link
Member

TD-er commented Sep 15, 2020

I still don't know for sure what @uzi18 meant.

Right now you do seem to make it selectable to output multiple values instead of 1.
But if you make the valueCount fixed to 2, even though you output only one value, you may break stuff.
At least Domoticz is very picky in the valueCount and order of values.

@uzi18
Copy link
Contributor

uzi18 commented Sep 17, 2020

@TD-er @clumsy-stefan when change from/to combined mode please change also valuecount and device type in device configuration.

@TD-er
Copy link
Member

TD-er commented Sep 23, 2020

For this PR, it is good to know I am now dealing with the buggy handling of changing number of output values.
So if that's merged this PR should be changed accordingly and then this can also be merged.

@clumsy-stefan
Copy link
Contributor Author

Ok, I'm happy to change this PR accordingly, but first have to find out how to do that (changing the number of output values at runtime)…

@TD-er
Copy link
Member

TD-er commented Sep 24, 2020

I will add some documentation to the PR, and you may be the first one to check if it is sufficient :)

@TD-er
Copy link
Member

TD-er commented Sep 25, 2020

It has been merged, good luck :)

@@ -42,12 +44,12 @@ boolean Plugin_013(byte function, struct EventStruct *event, String& string)
{
Device[++deviceCount].Number = PLUGIN_ID_013;
Device[deviceCount].Type = DEVICE_TYPE_DUAL;
Device[deviceCount].VType = Sensor_VType::SENSOR_TYPE_SINGLE;
Device[deviceCount].VType = SENSOR_TYPE_DUAL;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be using the Sensor_VType:: prefix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, sure, otherwise it won't compile anyway… I changed it but did not yet commit…

Device[deviceCount].Ports = 0;
Device[deviceCount].PullUpOption = false;
Device[deviceCount].InverseLogicOption = false;
Device[deviceCount].FormulaOption = true;
Device[deviceCount].ValueCount = 1;
Device[deviceCount].ValueCount = 2;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should leave the default to 1, as it is used by all instances out there.
And make it configurable to select a different number of outputs.
See the P026_Sysinfo.ino for an example and I also added the new Plugin functions to the Pxxx_Template.ino.

For example, also add this:

     Device[deviceCount].OutputDataType = Output_Data_type_t::Simple;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I'll have a look at it

@@ -257,7 +262,7 @@ boolean Plugin_013(byte function, struct EventStruct *event, String& string)
addLog(LOG_LEVEL_INFO,log);
switchstate[event->TaskIndex] = state;
UserVar[event->BaseVarIndex] = state;
event->sensorType = Sensor_VType::SENSOR_TYPE_SWITCH;
event->sensorType = SENSOR_TYPE_SWITCH;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should use the Sensor_VType:: prefix

if (operatingMode == OPMODE_VALUE)
event->sensorType = SENSOR_TYPE_SINGLE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

tonhuisman added a commit to tonhuisman/ESPEasy-1 that referenced this pull request Jan 28, 2023
@TD-er
Copy link
Member

TD-er commented Apr 11, 2023

Is included in #4442

@TD-er TD-er closed this Apr 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants