maustec / edge-o-matic-3000 Goto Github PK

The last push fixed the connection problem. But the edge-o-matic does not control speed.

another thing I noticed, there needs to be a small delay before motor on and detection
I find when the motor turns on there is kind of a defualt twitch reaction, but obviously the person isnt close yet, this leads to a lot of false starts
I think maybe a 1s minimum on time would be useful to stop that

The specific version of ESP-IDF cannot be found on Linux. It builds fine on my machine, so perhaps I should change the action runner to macos-latest instead and see if that fixes it? PlatformIO is usually a bit behind ESP-IDF in releases, so I am not surprised there is struggle here. This is still better than manually trying to orchestrate builds against the IDF.

Except, of course, for the instances where we are intentionally printing output to the serial console, everything else should use the system logger since it's better also can be disabled for production builds.

The lack of https: support for the WebSocket connection to the Edge-o-Matic is making it really friggin hard to use modern web features, like Bluetooth support and Buttplug.io.

We should figure out how to upgrade the WS connection to WSS. I know the ESP has crypto functions. It does WiFi.

Please, gods of embedded programming, shine your wisdom upon me.

While the name is a joke (which should be kept), I like this idea.

So when in MoM mode, it will make you orgasm and use the clench sensor to determine when an orgasm happens. Once one does, it will stop for x seconds (with a randomizer to add on x seconds to it) and then start up again while keeping track of orgasms. This will allow it to basically force orgasm you over and over until someone stops it (or if #63 is added, apply those randomizers).

The buildup from the edge mode should still happen so that way when scripting a change in mode, you don't know if this will be an edge session or if MoM has been activated for a certain number of orgasms/time until it happens.

From 1017984LoL on the discord.

It would sure be nice to be able to set the EoM to go straight into either automatic or post mode when it is powered on.

I really like spending the night in bondage with a release timer set for morning. To wake up an hour before release with an edging session would be amazing.

When the device starts up, the initial sensitivity reading isn't sent to the digipot.

It would be nice if there was a min motor speed and a delay till motor ramp start settings. So that you could have more control over the spacing. It’s also be fun to have patterns for the delays. So that you could push someone closer and closer and then a long cool down.

Currently it seems like the "Allow Orgasm" button in the web interface, or when you reach the time limit using the "Edge+Orgasm" setting that the vibrator immediately goes to the set max speed. It would be nice if there was an option or if the default was to just use the set ramp up instead, just not stopping when reaching the arousal limit. It would be more of a sneaky surprise and much less jarring.

-- Credit to Sensory_Deprived on Discord for the idea.

I would like to set a minimum number of edges before getting an orgasm.

I would also like in both mins and edges a "add edges/mins from 0 to this setting" so that I can never know if the time for orgasm is at hand.

Since the Nobra drivers were created after the fork for V1, they were not compatible with the V1 firmware, and need to be rewritten as C files following the example of the Lovense driver. The CPP drivers are in the working tree.

It would be cool to have a setting in the JSON file that is an decimal (default of 0.00) that will lower "sensitivity_threshold" by that amount for every edge. This will allow for the device to use the stated sensitivity in the beginning, but as time goes on, the machine gets more and more sensitive to the users arousal and stops sooner and sooner. So the effect of being edged multiple times making it more likely to orgasm is minimized.

You may also have to set in the JSON a bottom limit for this so that it doesn't reach 0 and essentially turn off. Default it to 10 or so.

This is a "we should" as opposed to "we need to", but right now I'm building with Arduino which isn't very portable. I think the best practice in this regard is to use ESP-IDF toolchain.

I'd like a developer who is familiar with best practices specifically in regards to embedded / ESP-IDF development, and in application not just in theory, to weigh in here.

For those who like the idea of having it go all night, 5 hours isn't going to cut it. Allow us to set 720 at least if there needs to be a max limit. 9999 would be preferable, but at least 720 is 12 hours, so it needs to be "reset" twice a day for those who want to do this multi-days.

Customer is reporting that the motor start speed setting does not seem to change automatic functionality; motor still starts at 0.

This setting should also apply to manual mode, should it?

The arousal sensitivity should be decoupled from the calculation, and the threshold should purely be a threshold, with a separate setting for how sensitive increases are.

Otherwise, when lower arousal settings are used, tiny pressure fluctuations cause really large jumps. Temporary solution is to use pressure smoothing at 5 samples and calculate arousal on averages.

Warranty 70008

In the config load routine, the device should check if config.json is present. If it is not, it should be initialized with default values.

This also includes a bug where config is completely empty on device startup if there is no SD card, therefore loadConfigFromSD was never called.

I recall a popular Mistress mentioned that someone could just keep clenching to avoid the teasing rather than go through it again. This needs to be stopped. :)

Set a JSON value for "AdvoidenceTimerThreshold (INT) - ms" , "AdvoidenceTimerOnMin (INT) - seconds", "AdvoidenceTimerOnMax (INT) - seconds", "AdvoidenceTimerOffMin (INT) - seconds", "AdvoidenceTimerOffMax (INT) - seconds"

When the system detects a clench that last longer than AdvoidenceTimerThreshold, then pick a random number between AdvoidenceTimerMin and AdvoidenceTimerMax and turn on the vibrator and don't check for clenches. Once the timer has run it's course, turn off the vibrator for a random number between AdvoidenceTimerOffMin and AdvoidenceTimerOffMax. Once this is done, return to whatever mode was selected and start checking for clenches again.

This means that if someone tries to hold back the machine by clenching constantly, then the machine would just turn into a random vibrator until it detects that the user isn't constantly clenching.

I was wondering what software license is the source code using? And could it be made explicit with a LICENSE file?

On firmware v1.1.1.

It's possible to set the mode to LOCKOUT_POST_MODE via the WebSocket (by sending {"setMode": "LOCKOUT_POST_MODE"}), but this causes strange behavior on the EOM. It seems to behave similarly to Automatic mode, but there's no mode name shown at the top of the screen and no menu buttons are drawn at the bottom of the screen.

It seems that this mode used to be a distinct phase of Edging + Orgasm mode, but I guess that was replaced by the lock key in readings. This mode doesn't seem to be meaningful now.

Since enumerated values are stored as a number but look human-readable in code, this is confusing to non-programmers who are entering the value into the config file.

[E][hal-eeprom.cpp:48] eeprom_init(): Hex right before load:
[E][hal-eeprom.cpp:62] eeprom_init(): Hex right after load:

In Edge+Orgasm mode, The motor Max speed does not show in the Motor bar graph.

In edge+Orgasm mode, when the orgasm is permitted, the motor speed would jump to the max speed to quickly causing the sensor clench to detect a false orgasm. By bringing the motor to the max in a smooth ramp would help.

Following #34 , I should make sure there aren't any erroneous error-level log messages emitting from the HAL.

Greetings,
I'd like to be able to connect to the websocket, could you make a guide on what different commands and what is to be expected so that I could make my own remote interface?

Thanks